| View previous topic :: View next topic |
| Author |
Message |
glurps
Apprentice
Joined: 11 Mar 2004
Posts: 292
|
 Posted: Fri Sep 29, 2006 7:47 pm Post subject: emerging binary pkgs doesnt respect useflags |
 |
|
i just did a little experiment:
| Code: | $ USE=python emerge -av buildpkgonly weechat <------ +python
<...>
$ USE="-python" emerge -av --usepkgonly weechat <------ -python
These are the packages that would be merged, in order:
Calculating dependencies... done!
[binary N ] net-irc/weechat-0.1.9 USE="python ssl -debug -lua -perl -ruby" <----- +python
Total size of downloads: 0 kB
Would you like to merge these packages? [Yes/No] y
>>> Emerging (1 of 1) net-irc/weechat-0.1.9 to /
>>> Extracting info
>>> Extracting weechat-0.1.9
<... starts merging without complaining about mismatching useflags ...> |
it seams that portage doesnt check for obvious useflag mismatches when emerging binary packages.
python is listed in the weechat ebuild as a compiletime dependency not a runtime only. so above behaviour isnt "correct".
after above weechat is listed as having been emerged with python set. this good because the installed pkg actually does support python in this case. but it is also bad because some dependencies might be missing (which isnt the case for this pkg and the given useflag fliping).
| Code: | $ cat /var/db/pkg/net-irc/weechat-0.1.9/USE
x86 X .....python ....
|
so probably this wont work eighter: check CFLAGS.
i didnt test it yet but i hope that portage will at least pull any new dependencies that are the result of a useflag change.
but the first two problems are rather unfortunate already since they prevent using the same binarypkgdir across different stages (lets say a stage4 and a livecd-stage, using different profiles) when using catalyst.
does anyone know if the needed tests are in planning? |
|
| Back to top |
|
 |
Gergan Penkov
Veteran
Joined: 17 Jul 2004
Posts: 1464
Location: das kleinste Kuhdorf Deutschlands :)
|
| Posted: Fri Sep 29, 2006 7:55 pm Post subject: |
|
|
I haven't explored this at all lengths, but it seems the binary depresolver is completely broken in its current incarnation (it was probably portage-2.12_pre1-r3 or r2). Trying it on livecd stage1, after some breakages and trying to continue using the binpkgs, it becomes highly untrstworthy - no rebuild on use-flag changes (not to speak about c/cxx flags changes) emerges dependant Xorg libraries after gtk+ and so on.
_________________
"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack |
|
| Back to top |
|
|
nemoflo
n00b
Joined: 12 Aug 2003
Posts: 26
Location: France
|
|
| Back to top |
|
|
masterdriverz
Retired Dev
Joined: 28 Mar 2006
Posts: 391
Location: Far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the galaxy
|
| Posted: Sun Oct 01, 2006 5:27 pm Post subject: Re: emerging binary pkgs doesnt respect useflags |
|
|
| glurps wrote: | | i just did a little experiment |
Your experiment is fundamentally broken. You're making a package with certain options, and then expecting Portage to be able to magically change the resultant tarball. The only sane thing to do is die, or ignore the env changes (the current behaviour). |
|
| Back to top |
|
|
glurps
Apprentice
Joined: 11 Mar 2004
Posts: 292
|
| Posted: Mon Oct 02, 2006 1:32 am Post subject: Re: emerging binary pkgs doesnt respect useflags |
|
|
| masterdriverz wrote: | | glurps wrote: | | i just did a little experiment |
Your experiment is fundamentally broken.
<...>
The only sane thing to do is die, or ignore the env changes (the current behaviour). |
as you have realised there are (at least see below) two things that portage could do in such a situation. clearly what currently happens is the worse of the two for the reasons given above (the package is listed in /var/db/pkg with different useflags than those it was acctually compiled with - this leads to inconsistency.
also my experiment isnt broken at all. i did want to find out what portage does in the given situation. i found out and dont like the behaviour. you may tell me that i am a foul to have hoped for a different outcome if you wish but you cant tell me that my methodology is wrong. just because the result of my experiment wasnt what i hoped for doesnt mean that i have not used the right method to verify or falsify my thesis. acctually in this case i could verify my thesis as i expected portage not to behave as i want.
| masterdriverz wrote: | | You're making a package with certain options, and then expecting Portage to be able to magically change the resultant tarball. |
no i dont. i want it to eighter tell that the tarball doesnt fit my profile and exit or ....
| masterdriverz wrote: | | The only sane thing to do is die, or ignore the env changes (the current behaviour). |
.... compile the package instead. this would be the 3th possibity that you werent even able to think of. but i have to admit that i made a little mistake in my experiment too (which still doesnt mean it is "fundamentally broken", it just has a flaw): i didnt test if the same thing happens if i use --usepkg. i just did now and it does.
and no, the current behaviour is not sane, as it leads to inconsistancy.
currently if i use catalyst do build a stage4 and a livecd and use slightly different useflags i have to compile the packages that are needed for both twice. it is possible to have catalyst use binary packages from a different stage. but currently this is only usefull if there are no useflag changes. this wastes lots of time i can tell you.
oh their is a second option i can manually delete the packages that dont match the new useflags.... yes well this isnt really an option
so what i would emerge to behave like is this:
--usepkg : use binary package or if it doesnt exist or doesnt match the current settings for the given package compile it
--usepkgonly : use binary package or if it doesnt exist or doesnt match the current settings for the given package fail
if you still cant see why this might be usefull:
this wouldnt only speed up the creation of stages but also benefit anyone who would like to use binary packages. repositories containing binary pkgs for various pkgs possibly even different bpgks with different useflag settings could be created and could be used without the risk of fucking up our system just because you decided you dont need gnome and kde.
for this of course additional steps would be required for portage to know which if any of the bpkgs for a pkg matches the current useflags. i am too tired now to list the various ways to do so that i can think of but i hope you get the point now. |
|
| Back to top |
|
|
glurps
Apprentice
Joined: 11 Mar 2004
Posts: 292
|
| Posted: Mon Oct 02, 2006 1:39 am Post subject: |
|
|
| nemoflo wrote: | | In fact i think perhaps the portage developer team doesn't mind about for the moment. |
uh sorry didnt see your post at first because i got so heated when i read the other...
i will answer you tomorrow after reading the links you provided, thanks.
yes, i also think it has been a problem forever because way back i asked about this on this forum and got the answer that i now verified with my experiement.
masterdriverz: maybe you should read these pages too  |
|
| Back to top |
|
|
nemoflo
n00b
Joined: 12 Aug 2003
Posts: 26
Location: France
|
|
| Back to top |
|
|
|
Portage & Programming
And the portage team seems to not solve them.
