[gentoo-dev] Where to put prerelease vanilla kernels?

[gentoo-dev] Where to put prerelease vanilla kernels?

[Matt Rickard]

Portage currently does not contain any vanilla prerelease kernels (i.e.
2.4.22_pre7).  Bug 25107 is a request for this, and it seems reasonable
to have these kernels in portage, since we have pretty much every other
kernel branch you could think of in there :)

I'm wondering what's the best way to handle these?  First option is to
put them in vanilla-sources, for example,
vanilla-sources-2.4.22_pre7.ebuild.  If we ~ mask them, people using the
unstable profile will get these prerelease kernels if merging
vanilla-sources.  I'm not sure this is desired behavior, however, it IS
the unstable profile :)  We could also package.mask them here, this
might emphasize the fact that they are not supported.  However, _pre
kernels are generally quite stable, probably more so than many of the
other kernel branches we provide in portage.

Another option is to create a separate category for these, something
like pre-vanilla-sources.  This has the benefit that people who want
vanilla will get only vanilla, and not a prerelease -- regardless of
which profile they are using.

Any comments or suggestions on this?  I'm hoping for some kind of
consensus on where these should be put.

Thanks.

--
Matt Rickard
frogger@gentoo.org



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Alvaro Figueroa Cabezas]

On Jul 23 12:16, Matt Rickard wrote:
> Portage currently does not contain any vanilla prerelease kernels (i.e.
> 2.4.22_pre7).  Bug 25107 is a request for this, and it seems reasonable
> to have these kernels in portage, since we have pretty much every other
> kernel branch you could think of in there :)

Please excuse me for being a bit ignorant on the matter, but shouldn't
the naming policy should take care of it?

I'm assuming that just by naming a package either _alpha, _beta, _pre or
_rc, this package won't be chosen before any other package without a
suffix or that has _p. If it ain't like this, why is that?

(Naming policy available at http://www.gentoo.org/doc/en/policy.xml)

-- 
Alvaro Figueroa


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Chris Gianelloni]

Well, 2.4.22_pre1 is newer than 2.4.21, however, 2.4.21 is the latest
stable kernel from kernel.org.  Portage would see 2.4.22_pre1 as newer
and would merge it rather than 2.4.21 when someone installed
vanilla-sources.  The only effective way to separate them is to have
them in a separate container.

On Wed, 2003-07-23 at 03:10, Alvaro Figueroa Cabezas wrote:
> Please excuse me for being a bit ignorant on the matter, but shouldn't
> the naming policy should take care of it?
> 
> I'm assuming that just by naming a package either _alpha, _beta, _pre or
> _rc, this package won't be chosen before any other package without a
> suffix or that has _p. If it ain't like this, why is that?
-- 
Chris Gianelloni
Developer, Gentoo Linux


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Alvaro Figueroa Cabezas]

On Jul 23 15:16, Chris Gianelloni wrote:
> Well, 2.4.22_pre1 is newer than 2.4.21, however, 2.4.21 is the latest
> stable kernel from kernel.org.  Portage would see 2.4.22_pre1 as newer
> and would merge it rather than 2.4.21 when someone installed
> vanilla-sources.  The only effective way to separate them is to have
> them in a separate container.

But the policy clearly states that it will be calculated as a lower
version. Quote:

"Any of these suffixes may be immediately followed by a non-zero
positive integer, e.g., linux-2.4.0_pre10. Assuming identical version
parts, the suffixes are ordered as follows (lower means older): _alpha <
_beta < _pre < _rc < (nosuffix) < _p"

-- 
Alvaro Figueroa


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[donnie berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 23 July 2003 02:46, Alvaro Figueroa Cabezas wrote:
> "Any of these suffixes may be immediately followed by a non-zero
> positive integer, e.g., linux-2.4.0_pre10. Assuming identical version
> parts, the suffixes are ordered as follows (lower means older): _alpha <
> _beta < _pre < _rc < (nosuffix) < _p"

"Assuming identical version parts" is the section you seem to be missing.

2.4.22 != 2.4.21

so 2.4.22 would beat 2.4.22_pre2, but 2.4.22_pre2 would beat 2.4.21.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/HuolXVaO67S1rtsRAvVrAKC1yJkFTMOmCoDt2UpC7oMCjFfOqQCgx7mR
zUnxEtaZHpTBu7ku2aSjNEQ=
=abdx
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Alvaro Figueroa Cabezas]

On Jul 23 15:03, donnie berkholz wrote:

> so 2.4.22 would beat 2.4.22_pre2, but 2.4.22_pre2 would beat 2.4.21.

Ohh I see. Shouldn't the policy be changed to make it the way I
missunderstood it? I really don't see the why in the way it is.

-- 
Alvaro Figueroa


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Peter Johanson]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On Wed, Jul 23, 2003 at 02:28:23PM +0600, Alvaro Figueroa Cabezas wrote:
> On Jul 23 15:03, donnie berkholz wrote:
> 
> > so 2.4.22 would beat 2.4.22_pre2, but 2.4.22_pre2 would beat 2.4.21.
> 
> Ohh I see. Shouldn't the policy be changed to make it the way I
> missunderstood it? I really don't see the why in the way it is.

the point is that 2.4.22 is newer than 2.4.22_pre2, which is newer than
2.4.21. The "beating" order is logical based on the order in which the
items were released.

-pete

-- 
Peter Johanson
<latexer@gentoo.org>

Key ID = 0x6EFA3917
Key fingerprint = A90A 2518 57B1 9D20 9B71  A2FF 8649 439B 6EFA 3917

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Chris Gianelloni]

Absolutely not.  The policy is the correct method for numbering
versions.  Your original understanding of how the policy used versions,
and how the kernel developers is incorrect.  You could consider the
2.4.22_pre kernels as 2.4.21_p kernels... they are patches on top of
2.4.21 that will someday in the future become 2.4.22, therefore they're
newer.  The portage policy is exactly in line with this.

On Wed, 2003-07-23 at 04:28, Alvaro Figueroa Cabezas wrote:
> Ohh I see. Shouldn't the policy be changed to make it the way I
> missunderstood it? I really don't see the why in the way it is.
-- 
Chris Gianelloni
Developer, Gentoo Linux


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[donnie berkholz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 23 July 2003 14:16, Chris Gianelloni wrote:
> Well, 2.4.22_pre1 is newer than 2.4.21, however, 2.4.21 is the latest
> stable kernel from kernel.org.  Portage would see 2.4.22_pre1 as newer
> and would merge it rather than 2.4.21 when someone installed
> vanilla-sources.  The only effective way to separate them is to have
> them in a separate container.

Or, as frogger suggested, to have them ~arch. If you want a "stable" kernel, 
you shouldn't be using ~arch anyway so you'll end up with the straight 
releases. If you want the pre's, rc's etc. emerge ~arch vanilla-sources.

The idea seems to have been almost passed over, and I don't see why.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/HuAkXVaO67S1rtsRAsyyAJ9jMCp4elNxONTT10LSgXGQKKShzACfQiGI
unqXBgtrBfVz+r16OZ9aH9c=
=ick0
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Jay Pfeifer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My thoughts... also posted on bug 25107...

best just to put a pkg_postinst warning similar to the one from 
http://www.kernel.org/prepatch.html. I think this is better than putting the 
ebuilds in the package.mask. I would also want the package to be 
'sys-kernel/vanilla-prepatch-sources' or  'sys-kernel/prepatch-sources'. 
Probably the first. This would keep users wanting the latest stable version, 
as deemed by kernel.org, from accidentally emerging the wrong 
vanilla-sources. 

Jay

On Wednesday 23 July 2003 11:16 am, Matt Rickard wrote:
>
> Any comments or suggestions on this?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/Hsnbe5xY3v0FhjgRAuwoAJ9x3RJim3mCX6i8UBllz8UydDjyOgCfWAdF
s12C9r8AnhVAiRNOyXbeTQ8=
=gx25
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Matt Rickard]

On Wed, 23 Jul 2003 12:45:55 -0500
Jay Pfeifer <pfeifer@gentoo.org> wrote:
> 
> My thoughts... also posted on bug 25107...
> 
> best just to put a pkg_postinst warning similar to the one from 
> http://www.kernel.org/prepatch.html. I think this is better than
> putting the ebuilds in the package.mask. I would also want the package
> to be 'sys-kernel/vanilla-prepatch-sources' or 
> 'sys-kernel/prepatch-sources'. Probably the first. This would keep
> users wanting the latest stable version, as deemed by kernel.org, from
> accidentally emerging the wrong vanilla-sources. 
> 

I put it in 'sys-kernel/vanilla-prepatch-sources' and added a
pkg_postinst warning.  Just committed it and closed bug 25107.

--
Matt Rickard
frogger@gentoo.org

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Dhruba Bandopadhyay]

Matt Rickard wrote:
> Portage currently does not contain any vanilla prerelease kernels (i.e.
> 2.4.22_pre7).  Bug 25107 is a request for this, and it seems reasonable
> to have these kernels in portage, since we have pretty much every other
> kernel branch you could think of in there :)

Yes.  Absolutely right.

> I'm wondering what's the best way to handle these?  First option is to

How about splitting development-sources into 2.6.x and 2.4.x trees? 
It's not like 2.6.x is the only branch undergoing 'development'.

As to how to split this I'll leave up to you.  Adding a suffix to it to 
give rise to two categories may be an idea.  Just some thoughts.

With regards.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Jay Pfeifer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

See below.

On Wednesday 23 July 2003 01:06 pm, Dhruba Bandopadhyay wrote:
>
> How about splitting development-sources into 2.6.x and 2.4.x trees?
> It's not like 2.6.x is the only branch undergoing 'development'.

the 2.5/2.6.x is a beta patch, not a prepatch for now. It goes under 
sys-kernel/development-sources. Until there is a 2.6.0 release and subsequent 
prepatches against 2.6.0 as a 2.6.1preX - @ that time it would go into the 
proposed sys-kernel/vanilla-prepatch-sources.

Jay

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/HtLde5xY3v0FhjgRAnKQAJ9UMeJlqN8BBcSaKVnV6iFIJPukJwCeNESt
Rt4qWoLrHyj5XIN9KwmGTBw=
=EpLP
-----END PGP SIGNATURE-----


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

On Wed, Jul 23, 2003 at 12:16:03PM -0400, Matt Rickard wrote:
> I'm wondering what's the best way to handle these?  First option is to
> put them in vanilla-sources, for example,
> vanilla-sources-2.4.22_pre7.ebuild.  If we ~ mask them, people using the
> unstable profile will get these prerelease kernels if merging
> vanilla-sources.  I'm not sure this is desired behavior, however, it IS
> the unstable profile :)  

Its more like the testing. ~arch is when a developer deems his package ready
for inclusion. 

> Another option is to create a separate category for these, something
> like pre-vanilla-sources.  This has the benefit that people who want
> vanilla will get only vanilla, and not a prerelease -- regardless of
> which profile they are using.

I don't like this idea (even though I'm in the minority here :). First of
all, when the _pre's are finished and the stable kernel is released, people
which are using pre-vanilla-sources will be stuck at the latest _pre (or
_testing).

And when they emerge the vanilla-sources, they'll miss the next _pre cycle.
 
Personally, I would go for package.mask

Wkr,
	Sven Vermeulen

-- 
    Save some animals, eat a vegetarian.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Georgi Georgiev]

[-- Attachment #1: Type: text/plain, Size: 3028 bytes --]

On 24/07/2003 at 10:28:57(+0200), Sven Vermeulen used 1.6K just to say:
> On Wed, Jul 23, 2003 at 12:16:03PM -0400, Matt Rickard wrote:
> > I'm wondering what's the best way to handle these?  First option is to
> > put them in vanilla-sources, for example,
> > vanilla-sources-2.4.22_pre7.ebuild.  If we ~ mask them, people using the
> > unstable profile will get these prerelease kernels if merging
> > vanilla-sources.  I'm not sure this is desired behavior, however, it IS
> > the unstable profile :)  
> 
> Its more like the testing. ~arch is when a developer deems his package ready
> for inclusion. 
> 
> > Another option is to create a separate category for these, something
> > like pre-vanilla-sources.  This has the benefit that people who want
> > vanilla will get only vanilla, and not a prerelease -- regardless of
> > which profile they are using.
> 
> I don't like this idea (even though I'm in the minority here :). First of
> all, when the _pre's are finished and the stable kernel is released, people
> which are using pre-vanilla-sources will be stuck at the latest _pre (or
> _testing).
> 
> And when they emerge the vanilla-sources, they'll miss the next _pre cycle.
>  
> Personally, I would go for package.mask

Wow... I was getting scared seeing how this thread developed, but in the end,
after reading this post, I realized that the world has not gone *completely*
mad, after all.

I fully support the opinions stated above, and I simply cannot comprehend what
the big deal with ~arch masking vanilla-sources is. Even *considering* the
option of a separate package is ridiculous. As long as developers are careful
enough to not remove the ~arch mask from any _pre kernel, I am perfectly fine,
and I believe there wouldn't be anyone who isn't fine. What are we trying to do
-- make sure people who insist on running the *unstable* profile actually don't
get the "unstable" sources. There is also the package.mask if you feel that is
not enough, but this was also mentioned already. And the decision that was
taken is ... weird.  What is the idea in having unstable (i.e. ~masked)
packages in the first place? Are you going to keep only stable versions in
vanilla-sources? What's the point? Why not move all _pre, _alpha ane _beta
versions of packages in separate directories? As it was already mentioned, _pre
kernels are more stable than many other packages. The first one I can think of
is gentoo-sources, that insisted on corrupting my filesystem every now and
then, so I couldn't upgrade my glibc, without upgrading to vanilla-sources
first (some files were having funny contents during compilation but it was hard
to reproduce), and I am running vanilla-sources ever since.

Sorry for the tone, but I feel frustrated.

-- 
()   Georgi Georgiev   () A committee is a life form with six or more  ()
()    chutz@gg3.net    () legs and no brain. -- Lazarus Long, "Time    ()
()  +81(90)6266-1163   () Enough For Love"                             ()

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Matt Rickard]

> 
> I fully support the opinions stated above, and I simply cannot
> comprehend what the big deal with ~arch masking vanilla-sources is.
> Even *considering* the option of a separate package is ridiculous. As
> long as developers are careful enough to not remove the ~arch mask
> from any _pre kernel, I am perfectly fine, and I believe there
> wouldn't be anyone who isn't fine. What are we trying to do-- make
> sure people who insist on running the *unstable* profile actually
> don't get the "unstable" sources. 

Well the fact is that an unstable kernel can be a whole lot more
problematic than an unstable userland package.  With userland, if it
crashes, oh well, you can start it up again.  With an unstable kernel
you run the risk of hard locks and corrupted filesystems.

I know that I've used vanilla-sources on some systems where I'm using
the ~arch profile, because I KNOW it will work correctly.  Sometimes I
don't want to mess around with experimental kernel patches.

There is also the package.mask if you feel that is
> not enough, but this was also mentioned already. And the decision that
> was taken is ... weird.  What is the idea in having unstable (i.e.
> ~masked) packages in the first place? Are you going to keep only
> stable versions in vanilla-sources? What's the point? 

The point is that vanilla-sources gets you stable release kernels all
the time.

>Why not move all
> _pre, _alpha ane _beta versions of packages in separate directories?
> As it was already mentioned, _pre kernels are more stable than many
> other packages. 

Well beta kernels already have their own category as
development-sources.  It is my understanding that this _pre category
will also contain _rc kernels.

>The first one I can think of is gentoo-sources, that
> insisted on corrupting my filesystem every now and then, so I couldn't
> upgrade my glibc, without upgrading to vanilla-sources first (some
> files were having funny contents during compilation but it was hard to
> reproduce), and I am running vanilla-sources ever since.

I hope you filed a bug report :)  I don't use gentoo-sources myself so I
can't comment anymore than that.

> 
> Sorry for the tone, but I feel frustrated.

No problem, you raise some issues that definitely do need to be
addressed.

--
Matt Rickard
frogger@gentoo.org


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1192 bytes --]

On Thursday 24 July 2003 15:07, Matt Rickard wrote:
> > I fully support the opinions stated above, and I simply cannot
> > comprehend what the big deal with ~arch masking vanilla-sources is.
> > Even *considering* the option of a separate package is ridiculous. As
> > long as developers are careful enough to not remove the ~arch mask
> > from any _pre kernel, I am perfectly fine, and I believe there
> > wouldn't be anyone who isn't fine. What are we trying to do-- make
> > sure people who insist on running the *unstable* profile actually
> > don't get the "unstable" sources.
>
> Well the fact is that an unstable kernel can be a whole lot more
> problematic than an unstable userland package.  With userland, if it
> crashes, oh well, you can start it up again.  With an unstable kernel
> you run the risk of hard locks and corrupted filesystems.

As far as I know we don't actually compile any kernel automatically. That 
means that it still requires user action to actually install a prekernel. 
That means that a user must actually decide on running a prekernel

Paul

-- 
Paul de Vrieze
Researcher
Mail: pauldv@cs.kun.nl
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Terje Kvernes]

Paul de Vrieze <pauldv@gentoo.org> writes:

  [ ... ]

> As far as I know we don't actually compile any kernel
> automatically. That means that it still requires user action to
> actually install a prekernel.  That means that a user must actually
> decide on running a prekernel

  my main problem with this is that Gentoo for obvious reasons never
  unmerge a kernel.  if ~x86 would yield a few kernels every week for
  someone who has both vanilla-sources and development-sources
  installed, well, that'll take _space_.

  first in DISTFILES, then as a package if one uses buildpkg and last
  under /usr/src.  for most people, this will be two compressed and
  one unpacked piece of kernel source for each installed kernel.

  this would, if nothing else, make "emerge -U world" slightly
  annoying to deal with.

-- 
Terje

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Matt Rickard]

> 
> > Another option is to create a separate category for these, something
> > like pre-vanilla-sources.  This has the benefit that people who want
> > vanilla will get only vanilla, and not a prerelease -- regardless of
> > which profile they are using.
> 
> I don't like this idea (even though I'm in the minority here :). First
> of all, when the _pre's are finished and the stable kernel is
> released, people which are using pre-vanilla-sources will be stuck at
> the latest _pre (or_testing).

I think the idea here was to also include _rc kernels in this category. 
Since an _rc generally becomes the stable when it is deemed worthy,
people shouldn't really be behind here (except by version number, not
content).

In the case where there are a couple last minute changes from the final
_rc to the next stable release, then yes, this could be a problem :\ 
(although I don't know if this actually happens or not).

> 
> And when they emerge the vanilla-sources, they'll miss the next _pre
> cycle.
>  
> Personally, I would go for package.mask
> 

package.mask is what I was really trying to avoid.  It's always a pain
to have to unmask a package if you want to use it.  These kernels are
usually quite stable, and I don't think they deserve to be hard masked.

I'm still open to suggestions on this though...

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Thomas de Grenier de Latour]

On Thu, 24 Jul 2003 08:56:44 -0400
Matt Rickard <frogger@gentoo.org> wrote:

> package.mask is what I was really trying to avoid.  It's always a pain
> to have to unmask a package if you want to use it.

It's not anymore such a pain with custom package.(un)mask, this feature
just lacks documentation.

   I personnaly thinks using package.mask to mask prereleases of kernels
is the better solution. This way, a user has much more possibilities to
control which versions he wants to use:
 o Does he only want stable version? He has no changes to do.
 o Does he want to test everything? He can unmask
"sys-kernel/vanilla-sources"
 o Does he want to test _rc but not _pre, in 2.4.22 branch? He can
unmask ">=sys-kernel/vanilla-sources-2.4.22_rc1" and mask
">sys-kernel/vanilla-sources-2.4.22*"
 o etc.

There is no such to specify a custom policy with ~arch masking.

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Thomas de Grenier de Latour]

On Thu, 24 Jul 2003 15:49:21 +0200
Thomas de Grenier de Latour <degrenier@easyconnect.fr> wrote:

>  o Does he want to test _rc but not _pre, in 2.4.22 branch? He can
> unmask ">=sys-kernel/vanilla-sources-2.4.22_rc1" and mask
> ">sys-kernel/vanilla-sources-2.4.22*"

Oops, yes, unmasking "=sys-kernel/vanilla-sources-2.4.22_rc*" would be
simpler :)

-- 
TGL.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Where to put prerelease vanilla kernels?

[Alvaro Figueroa]

On Thu, 2003-07-24 at 02:28, Sven Vermeulen wrote:
> Personally, I would go for package.mask

I like this solution better. I don't know how many of you know that on
some 2.4 version, Marcelo forgot to add a patch that was added to -rc4,
to the realeased kernel. So I had to use this kernel on splack
(slackware for sparc) instead of the released kernel, because this patch
was extremely important on archs other than intel.

If you had a package mask, this could be handleded more gracefully.

-- 
Alvaro Figueroa


--
gentoo-dev@gentoo.org mailing list