Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 149508 - Missing >=sys-kernel/linux-headers-2.5 from no-nptl/2.4 profile package.mask
Summary: Missing >=sys-kernel/linux-headers-2.5 from no-nptl/2.4 profile package.mask
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Release Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-29 05:30 UTC by Christian Schlotter
Modified: 2007-10-04 20:07 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Schlotter 2006-09-29 05:30:48 UTC
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
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 06:31:38 UTC
Go fix paludis, there's nothing wrong with the profiles.
Comment 2 Ciaran McCreesh 2006-09-29 06:40:35 UTC
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.
Comment 3 Ciaran McCreesh 2006-09-29 07:11:23 UTC
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.
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 07:41:55 UTC
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
Comment 5 Ciaran McCreesh 2006-09-29 07:52:28 UTC
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.
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 08:12:19 UTC
(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>
Comment 7 Ciaran McCreesh 2006-09-29 08:17:32 UTC
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.
Comment 8 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 08:23:17 UTC
(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.
Comment 9 Ciaran McCreesh 2006-09-29 08:32:33 UTC
(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.
Comment 10 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 08:45:04 UTC
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.
Comment 11 Stephen Bennett (RETIRED) gentoo-dev 2006-09-29 08:46:09 UTC
Fixed in no-nptl/2.4. Please reopen if any other profiles suffer from the same problem.
Comment 12 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 08:50:54 UTC
(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.



Comment 13 Ciaran McCreesh 2006-09-29 08:59:16 UTC
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...
Comment 14 Seemant Kulleen (RETIRED) gentoo-dev 2006-09-29 09:01:41 UTC
x86 and hardened, can you guys have a look-see?

thanks!
Comment 15 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 09:03:57 UTC
(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
Comment 16 Ciaran McCreesh 2006-09-29 09:11:41 UTC
(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.
Comment 17 Stephen Bennett (RETIRED) gentoo-dev 2006-09-29 09:36:12 UTC
> 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.
Comment 18 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 10:07:58 UTC
(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
Comment 19 Ciaran McCreesh 2006-09-29 10:13:53 UTC
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.
Comment 20 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 10:37:21 UTC
(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.
Comment 21 Ciaran McCreesh 2006-09-29 10:47:41 UTC
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...
Comment 22 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 10:57:25 UTC
(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.
Comment 23 Ciaran McCreesh 2006-09-29 11:02:53 UTC
(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.
Comment 24 Jakub Moc (RETIRED) gentoo-dev 2006-09-29 11:06:45 UTC
(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.
Comment 25 Chris Gianelloni (RETIRED) gentoo-dev 2006-09-29 13:45:04 UTC
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.
Comment 26 Chris Gianelloni (RETIRED) gentoo-dev 2006-09-29 14:16:13 UTC
<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.
Comment 27 Chris Gianelloni (RETIRED) gentoo-dev 2006-09-29 14:18:06 UTC
Reassigning to release, adding sparc and embedded, and removing x86.
Comment 28 Alec Warner (RETIRED) archtester gentoo-dev Security 2006-09-29 18:15:20 UTC
(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".
Comment 29 Ciaran McCreesh 2006-09-29 18:25:46 UTC
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.
Comment 30 Brian Harring (RETIRED) gentoo-dev 2006-09-29 19:01:56 UTC
(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...

Comment 31 Diego Elio Pettenò (RETIRED) gentoo-dev 2006-09-29 21:27:19 UTC
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.
Comment 32 Ciaran McCreesh 2006-09-30 05:24:47 UTC
(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
Comment 33 Jason Stubbs (RETIRED) gentoo-dev 2006-09-30 23:23:01 UTC
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.
Comment 34 Gustavo Zacarias (RETIRED) gentoo-dev 2006-10-10 12:55:25 UTC
sparc done, since it breaks nothing in particular.
Comment 35 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2007-05-02 19:12:06 UTC
$ 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
Comment 36 Zac Medico gentoo-dev 2007-05-02 22:18:30 UTC
(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.
Comment 37 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2007-05-02 22:39:19 UTC
(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.
Comment 38 Arfrever Frehtes Taifersar Arahesis (RETIRED) gentoo-dev 2007-05-03 14:11:35 UTC
(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.
Comment 39 Jakub Moc (RETIRED) gentoo-dev 2007-10-04 20:07:32 UTC
Yaaawn; 2.4 profiles are unsupported and this bug does nowhere.