Hi! I found the following inconsistency when comparing the behaviour of portage and paludis: Both the x86/gcc2 profile and the x86/no-nptl/2.4 profile exclusively use the 2.4 kernel headers. gcc2's and no-nptl/2.4's "packages" files contain the line "<sys-kernel/linux-headers-2.5", but only gcc2's "package.mask" contains the line ">=sys-kernel/linux-headers-2.5". In the no-nptl/2.4 case this means, that # emerge --pretend '>linux-headers-2.5' refuses to update ("!!! All ebuilds that could satisfy ">linux-headers-2.5" have been masked."), while # paludis -pi '>linux-headers-2.5' wants to upgrade: * sys-kernel/linux-headers-2.6.17-r1 [U 2.4.26-r1] -gcc64 * virtual/os-headers-2.6.17-r1::virtuals [U 2.4.26-r1] Unfortunately I could not find a definition of the meaning of the packages file in a profiles directory, so I don't know which behaviour is correct. But I think that ">=sys-kernel/linux-headers-2.5" should also be added to no-nptl/2.4's "package.mask". Best regards Christian
Go fix paludis, there's nothing wrong with the profiles.
Incorrect, Jakub. Profiles that use <entries also need to use package.mask if the intention is to prevent later versions from being installed. <entries on their own are merely used to require slotted things.
For an example of how it's supposed to be done... grep glibc /usr/portage/profiles/default-linux/x86/no-nptl/{package.mask,packages} /usr/portage/profiles/default-linux/x86/no-nptl/package.mask:>=sys-libs/glibc-2.4 /usr/portage/profiles/default-linux/x86/no-nptl/packages:<sys-libs/glibc-2.4 Note the pairing of entries.
What's the point in duplicating the entries? portage handles this correctly, pkgcore handles this correctly, just paludis lets you unmerge versions mandated by profile... Portage 2.1.2_pre1-r4 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 i686) # echo ">=sys-kernel/linux-headers-2.5" >> /usr/portage/profiles/default-linux/x86/2006.1/packages # emerge -pv \<linux-headers-2.5 These are the packages that would be merged, in order: Calculating dependencies !!! All ebuilds that could satisfy "<linux-headers-2.5" have been masked. !!! One of the following masked packages is required to complete your request: - sys-kernel/linux-headers-2.0.40-r1 (masked by: profile, missing keyword) - sys-kernel/linux-headers-2.4.33.3 (masked by: profile) - sys-kernel/linux-headers-2.2.26-r1 (masked by: profile, missing keyword) - sys-kernel/linux-headers-2.4.26-r1 (masked by: profile) For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. # pmerge -p \<linux-headers-2.5 * Resolving... !!! Resolver returned [<atom <sys-kernel/linux-headers-2.5 @#-4872f254>] !!! resolution failed Another example (slotted stuff now): # emerge -pv \<gcc-3 These are the packages that would be merged, in order: Calculating dependencies !!! All ebuilds that could satisfy "<gcc-3" have been masked. !!! One of the following masked packages is required to complete your request: - sys-devel/gcc-2.95.3-r9 (masked by: profile) For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. # pmerge -p \<gcc-3 * Resolving... !!! Resolver returned [<atom <sys-devel/gcc-3 @#-486f9254>] !!! resolution failed
The reason profiles package.mask was introduced was to allow for cases like requiring gcc 3 in system but not masking gcc 2. The information isn't being duplicated here, the two files mean different things.
(In reply to comment #5) > The reason profiles package.mask was introduced was to allow for cases like > requiring gcc 3 in system but not masking gcc 2. The information isn't being > duplicated here, the two files mean different things. sys-kernel/linux-headers is not slotted at all, so that argument is moot here. You've chosen to implement things differently from portage, and now you are requesting to change profiles to match paludis behaviour? Portage handles this correctly, as shown above. You are allowing users to shoot themselves in the foot, where portage does not (in other words, paludis does not honor profiles mask in packages files). man portage: <snip> packages This file serves two purposes. The first is to mask out specific packages/versions on a per-profile basis. The second is to provide the list of packages that compose the special system set. Example: # i am a comment ! # only allow versions of glibc less than 2.3 <sys-libs/glibc-2.3 </snip>
We've implemented it the way it's supposed to work. As I've already told you, 'man portage' is way out of date and makes no mention of profile-subdirectory package.mask. The way profiles should be is as explained in comment #3. Please reassign this bug to the profile owner and fix the summary.
(In reply to comment #7) > We've implemented it the way it's supposed to work. Well, not really. You've implemented this the way you'd _like it_ to work, which is completely different thing. :=) I.e., you've ommited backwards compatibility there. Sorry, but IMHO this bug belongs to paludis bugtracker, not here.
(In reply to comment #8) > (In reply to comment #7) > > We've implemented it the way it's supposed to work. > > Well, not really. You've implemented this the way you'd _like it_ to work, > which is completely different thing. :=) I.e., you've ommited backwards > compatibility there. Sorry, but IMHO this bug belongs to paludis bugtracker, > not here. Incorrect. The profile under discussion depends upon undefined behaviour. The correct way to do what this profile wants is explained in comment #3. Now, be a good little bug wrangler and reassign this.
CCing portage folks, since I'm getting tired of this discussion. You broke backwards compatibility in paludis on purpose, so don't blame the profiles.
Fixed in no-nptl/2.4. Please reopen if any other profiles suffer from the same problem.
(In reply to comment #11) > Fixed in no-nptl/2.4. Please reopen if any other profiles suffer from the same > problem. Sure they do, like hardened/x86/2.6 - and plenty of others that define minimal package versions on unslotted packages but don't p.mask the lower versions. This is not a profiles bug.
Jakub, did you read up on why package.mask was added to profile subdirectories yet? Your comments show a clear lack of understanding of what's being discussed...
x86 and hardened, can you guys have a look-see? thanks!
(In reply to comment #13) > Jakub, did you read up on why package.mask was added to profile subdirectories > yet? Your comments show a clear lack of understanding of what's being > discussed... Sure I did. Go read the profiles and see how many of them just set minimal required version without p.masking the lower ones (and no, I'm not talking about slotted packages now). You are requesting to duplicate all the info across two files for no apparent reason except that paludis implementation differs from de facto portage standard and is throwing away this info included in profiles/*/packages
(In reply to comment #15) > Sure I did. Go read the profiles and see how many of them just set minimal > required version without p.masking the lower ones (and no, I'm not talking > about slotted packages now). It isn't an issue for > and >= on non-SLOTted packages. x86 and hardened are not affected. > You are requesting to duplicate all the info > across two files for no apparent reason except that paludis implementation > differs from de facto portage standard and is throwing away this info included > in profiles/*/packages It's not duplicating information. The two files mean different things. You've already been told that several times.
> Sure I did. Go read the profiles and see how many of them just set minimal > required version without p.masking the lower ones (and no, I'm not talking > about slotted packages now). http://devmanual.gentoo.org/profiles/packages/index.html Minimal versions are fine. Maximal versions require an accompanying package.mask entry. Again, if you can point to other profiles that do this and need updating, please reopen. The examples you gave specify minimum versions and so are unaffected.
(In reply to comment #17) > Minimal versions are fine. hardened/x86/2.6 is broken: $ emerge -pv \<linux-headers-2.5 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD] sys-kernel/linux-headers-2.4.26-r1 [2.6.17-r1] USE="-gcc64" 30,051 kB Whatever, you are missing "masked by profile" state in paludis, be it minimal version or maximal version, that behaviour simply doesn't match portage. Other affected profiles (incomplete, really don't have time to wade through stuff that's a non-issue for portage) default-linux/sparc/sparc{32,64}/2006.1/2.4 uclibc - all 2.4 subprofiles
Uh, Jakub, all you're doing is demonstrating what I said about Portage inconsistencies, and showing that it's not a Paludis specific issue at all.
(In reply to comment #19) > Uh, Jakub, all you're doing is demonstrating what I said about Portage > inconsistencies, and showing that it's not a Paludis specific issue at all. Sure. Paludis allowing users to up/downgrade to versions disallowed by profiles' packages file, while portage/pkgcore disallowing the same is apparently a portage inconsistency.
Jakub, are you even reading your own posts? You're pointing out Portage inconsistencies yourself, and then claim that Portage isn't inconsistent. Christian: Thanks for reporting. Please don't let Jakub's behaviour here put you off future bug reports...
(In reply to comment #21) > Jakub, are you even reading your own posts? You're pointing out Portage > inconsistencies yourself, and then claim that Portage isn't inconsistent. Sure I do. I don't see any portage inconsistency anywhere, it behaves exactly as documented in the manpage that you dislike that much. (If you are referring to hardened/x86/2.6 profile, it's broken, doesn't state minimal linux-headers version, that has nothing to do with portage inconsistencies at all.) And sorry, paludis is not a refence package manager here, what you've implemented "as it's supossed to work" is your own fight really, not a reason for QA to go mess with the profiles.
(In reply to comment #22) > (In reply to comment #21) > > Jakub, are you even reading your own posts? You're pointing out Portage > > inconsistencies yourself, and then claim that Portage isn't inconsistent. > > Sure I do. I don't see any portage inconsistency anywhere, it behaves exactly > as documented in the manpage that you dislike that much. What? No it doesn't. For starters, that man page doesn't talk about subdirectory package.mask files. We went over this already. > And sorry, paludis is not a refence package manager here, what you've > implemented "as it's supossed to work" is your own fight really, not a reason > for QA to go mess with the profiles. QA fixed a profile because it was wrong. Paludis has nothing to do with it.
(In reply to comment #17) > http://devmanual.gentoo.org/profiles/packages/index.html Oh wow, this is just wonderful - I wonder why I have never seen this there before. Ok, I see now - Bug 149536.
In the future, just send things dealing with profiles that Release Engineering work on/maintain directly to release@gentoo.org (this is meant for the people that put it on QA, not Christian) and we'll discuss it rationally, rather than having some knee-jerk reaction to what actually is a bug in the profiles that I created. It should have been obvious what the intended behavior is supposed to be, since I also created (correctly) the no-nptl profile. When I migrated the 2.4 profile from being sub-profiles of the versioned release profiles to no-nptl, I simply made a mistake and didn't mask linux-headers. This appears to have been resolved now, as I added this to alpha/no-nptl/2.4, too. Marking as FIXED.
<jakub> default-linux/sparc/sparc{32,64}/2006.1/2.4 <jakub> uclibc - all 2.4 subprofiles There's a couple more profiles that need to be done.
Reassigning to release, adding sparc and embedded, and removing x86.
(In reply to comment #0) > Hi! > > I found the following inconsistency when comparing the behaviour of portage and > paludis: > > Both the x86/gcc2 profile and the x86/no-nptl/2.4 profile exclusively use the > 2.4 kernel headers. gcc2's and no-nptl/2.4's "packages" files contain the line > "<sys-kernel/linux-headers-2.5", but only gcc2's "package.mask" contains the > line ">=sys-kernel/linux-headers-2.5". In the no-nptl/2.4 case this means, > that > # emerge --pretend '>linux-headers-2.5' > refuses to update ("!!! All ebuilds that could satisfy ">linux-headers-2.5" > have been masked."), while > # paludis -pi '>linux-headers-2.5' > wants to upgrade: > * sys-kernel/linux-headers-2.6.17-r1 [U 2.4.26-r1] -gcc64 > * virtual/os-headers-2.6.17-r1::virtuals [U 2.4.26-r1] > > Unfortunately I could not find a definition of the meaning of the packages file > in a profiles directory, so I don't know which behaviour is correct. But I > think that ">=sys-kernel/linux-headers-2.5" should also be added to > no-nptl/2.4's "package.mask". > from "man portage": /etc/make.profile/ deprecated make.defaults packages packages.build packages This file serves two purposes. The first is to mask out specific packages/versions on a per-profile basis. The second is to provide the list of packages that compose the special system set. # only allow versions of glibc less than 2.3 <sys-libs/glibc-2.3 Thus I'd say paludis is broken since versions lower than 2.3 should be "masked by profile".
Alec: You need to read back to the discussion when per subdirectory package.mask was introduced. The documentation is out of date here and doesn't reflect what's supposed to be happening.
(In reply to comment #29) > Alec: You need to read back to the discussion when per subdirectory > package.mask was introduced. The documentation is out of date here and doesn't > reflect what's supposed to be happening. URL's as per the norm, are useful...
Please freeze on this issue, such a behaviour change has to be discussed on gentoo-dev, as it involves way more than just 2.4 profiles. (Gentoo/*BSD profiles relies on the current behaviour too). QA: please try not to enforce policy before discussion, when the point is not cleared up before.
(In reply to comment #31) > QA: please try not to enforce policy before discussion, when the point is not > cleared up before. https://bugs.gentoo.org/show_bug.cgi?id=149536#c4
Just about everybody has the wrong idea here. 1) Specifying <sys-libs/glibc-2.4 in packages *does* mask >=sys-libs/glibc-2.4 and thus a corresponding entry in package.mask 2) What should be done is to specify >=sys-libs/glibc-2.4 and leave masking out altogether for packages The reason that package.mask was added to profiles was so that masking of atoms in packages could be killed off and it could become just a list of required packages.
sparc done, since it breaks nothing in particular.
$ LC_ALL="en_US" svn log -r6195 ------------------------------------------------------------------------ r6195 | zmedico | 2007-03-09 04:34:29 +0100 (Fri, 09 Mar 2007) | 1 line Remove legacy "masked by: profile" support as per bug #149508. Profiles should use package.mask to mask unwanted versions of system packages. ------------------------------------------------------------------------ $ 67 profiles still use this old masking style. When will they be fixed? $ cd /usr/portage/profiles $ packages=`find -name packages -exec grep -El "^(<|=|>)" {} \; | sort` $ for x in $packages ; do echo -e "\e[32m$x" ; grep -E "^(<|=|>).*" $x ; done
(In reply to comment #35) > $ LC_ALL="en_US" svn log -r6195 > ------------------------------------------------------------------------ > r6195 | zmedico | 2007-03-09 04:34:29 +0100 (Fri, 09 Mar 2007) | 1 line > > Remove legacy "masked by: profile" support as per bug #149508. Profiles should > use package.mask to mask unwanted versions of system packages. > ------------------------------------------------------------------------ All released versions of portage still have support for masking via the packages file. The above commit was reverted pending resolution of bug 170697.
(In reply to comment #36) > All released versions of portage still have support for masking via the > packages file. The above commit was reverted pending resolution of bug 170697. I saw it mentioned in [portage]/main/trunk/NEWS and it's still here.
(In reply to comment #35) > 67 profiles still use this old masking style. 93 profiles. > $ cd /usr/portage/profiles > $ packages=`find -name packages -exec grep -El "^(<|=|>)" {} \; | sort` > $ for x in $packages; do echo -e "\e[32m$x" ; grep -E "^(<|=|>).*" $x; done It should have be: $ cd /usr/portage/profiles $ packages=`find -name packages -exec grep -El "^\*?(<|=|>)" {} \; | sort` $ for x in $packages; do echo -e "\e[32m$x" ; grep -E "^\*?(<|=|>).*" $x; done (In reply to comment #37) > I saw it mentioned in [portage]/main/trunk/NEWS and it's still here. Thanks for fixing it.
Yaaawn; 2.4 profiles are unsupported and this bug does nowhere.
