[gentoo-dev] Policy for retirement of old gentoo "versions"

[gentoo-dev] Policy for retirement of old gentoo "versions"

[Barry Shaw]

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

Hi

Is there currently any method for the retiring of old "versions" of
gentoo?  I am concerned that at some point in the future one of the
package versions specified in /etc/make.profile/packages will be dropped
from portage as a part of the progressive culling of older ebuilds that
occurs over time.

I've had a look at the packages files for versions 1.4 and 2004.0 and
all of the packages have minimum specificed versions apart from
<sys-apps/shadow-5, so it appears to be an unlikely event.  That said,
if it did occur, any site with a large installed base of gentoo machines
could be in an awkward situation (particularly if packages are being
distributed as binaries).

Is there any policy/ideas/consensus among developers about how long a
particular "version" will remain supported in portage?  If not, it might
be a useful idea to set sunset dates for particular "versions" of gentoo
(as I doubt they are all going to be supported indefinitely).  If there
is a clear end date, it prevents anyone being caught out unexpectedly.

Baz


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

iD8DBQFA5LhLJvZkjpKMF2wRAplBAJ49nBhKknalZLpNfkBPs1Gwl0d//QCgrTUo
AHNqCCQ9D6Q0VcGQclLDqCQ=
=byMR
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Donnie Berkholz]

Barry Shaw said:
> Is there any policy/ideas/consensus among developers about how long a
> particular "version" will remain supported in portage?  If not, it might
> be a useful idea to set sunset dates for particular "versions" of gentoo
> (as I doubt they are all going to be supported indefinitely).  If there
> is a clear end date, it prevents anyone being caught out unexpectedly.

I generally keep a minimum of two ebuilds in, so testing for a newly
introduced problem is easier. If I put out seven ebuilds in two weeks for
some ungodly reason, I don't expect to be maintaining some sort of minimum
lifetime for each ebuild -- just the newest two will stick around.

We have no policy stating a minimum support lifetime for any given version
right now (AFAIK, of course), despite a push for it amidst emphasis for
Gentoo in the enterprise.

Donnie



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Chris Gianelloni]

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

On Thu, 2004-07-01 at 22:17, Donnie Berkholz wrote:
> Barry Shaw said:
> > Is there any policy/ideas/consensus among developers about how long a
> > particular "version" will remain supported in portage?  If not, it might
> > be a useful idea to set sunset dates for particular "versions" of gentoo
> > (as I doubt they are all going to be supported indefinitely).  If there
> > is a clear end date, it prevents anyone being caught out unexpectedly.
> 
> I generally keep a minimum of two ebuilds in, so testing for a newly
> introduced problem is easier. If I put out seven ebuilds in two weeks for
> some ungodly reason, I don't expect to be maintaining some sort of minimum
> lifetime for each ebuild -- just the newest two will stick around.
> 
> We have no policy stating a minimum support lifetime for any given version
> right now (AFAIK, of course), despite a push for it amidst emphasis for
> Gentoo in the enterprise.

As Donnie said, there is no policy laid out.

In general, I will keep 2 versions in portage.  Usually it is a stable
version, and a testing version.  Depending on the ebuild, I will leave
more versions.  For example, look at PXES or VMware Workstation.  PXES
is something that would be in use and probably not easily upgraded for
everyone, so I have left every stable version in portage since I added
the package.  VMware Workstation is a licensed product, so I leave one
version per license in the tree (3.x and 4.x).  There are currently 2
4.x ebuilds simply because one is still in testing.

Then you have packages like gcc/glibc, which usually stay in the tree
for much, much longer.

With an enterprise version of Gentoo, there will need to be much more
help in maintaining certain packages, simply because patches will need
to be back-ported to older versions and other such headaches that most
other distributions must deal with.

Right now, we simply don't have the manpower to keep up with such
things, which is why we do not make things version dependent, where
possible.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[William Kenworthy]

A few weeks back I filed a bug (since closed, but not resolved to my
satisfaction) on the premature removal of mm-sources and the fact that
no stable version was left in portage.  This had the effect of breaking
a number of perfectly working systems and leaving no alternative but to
move to another kernel as the masked versions did not work (at the time)
- a major hassle.  Without a kernel of that package in portage, packages
that depended on the installed kernel to build broke and couldnt be
installed.

I for one would like to see a policy for this as I feel that mm-sources
was done at the whim of a dev who was looking at his future, and wasnt
willing to consider the user base, leaving quite a number of us
stranded.  His justification seemed to be that mm-sources should be
considered a dev package, so I should not have bothered - bug closed.

BillK



On Fri, 2004-07-02 at 20:48, Chris Gianelloni wrote:
> On Thu, 2004-07-01 at 22:17, Donnie Berkholz wrote:
> > Barry Shaw said:
> > > Is there any policy/ideas/consensus among developers about how long a



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Grant Goodyear]

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

> A few weeks back I filed a bug (since closed, but not resolved to my
> satisfaction) on the premature removal of mm-sources and the fact that
> no stable version was left in portage.  This had the effect of breaking
> a number of perfectly working systems and leaving no alternative but to
> move to another kernel as the masked versions did not work (at the time)
> - a major hassle.

I'm probably missing something obvious, but even reading the original
bug report leaves me confused as to how a lack of stable mm-sources
ebuilds is breaking systems.  Once mm-sources is installed anything
that needs a kernel tree should build just fine.  (I don't think
we have anything in the tree that specifically requires mm-sources,
do we?)  If the problem is that somebody wants to install mm-sources but
can't because all ebuilds are arch-masked, then that's what
/etc/portage/package.keywords is for.

I don't know what the official thinking on this is, but off-the-cuff I
would tend to think that _all_ mm-sources ebuilds should really be arch
masked, since mm-sources is both bleeding-edge (by definition) and a
fast-moving target, so one expects that mm-sources ebuilds aren't likely
to be in the tree long enough to really become "stable".  Only
arch-masking release candidates seems a tad silly.  I suppose that one
might argue that they should be package masked, but since new kernels
aren't built and used automatically, I would prefer to just leave it up
to users to decide whether or not to build and use any given kernel.

> I for one would like to see a policy for this as I feel that mm-sources
> was done at the whim of a dev who was looking at his future, and wasnt
> willing to consider the user base, leaving quite a number of us
> stranded.  His justification seemed to be that mm-sources should be
> considered a dev package, so I should not have bothered - bug closed.

I agree that Greg's bug report was a tad terse, but I rather doubt that
your allegation of his motivation is correct.  

Now, as to the actual issue at hand, the common unwritten policy is that
packages generally have one (or at most a few) stable ebuild(s) and zero
or more arch-masked ebuilds.  Ideally, every mature package should have
a stable ebuild (preferably stable on every arch), but....  That said,
it's not a written policy because some packages have different needs,
and it's mostly up to the package maintainer to make those decisions.

Incidentally, we often have people suggest that ebuilds should never be
removed from the tree.  Then these sorts of problems would never arise.
If you've done a new install recently, though, you already know how long
it takes to download the initial tree, and that's with fairly active
pruning.  That's a problem that we don't have a really good solution
just yet, so for the moment we try to keep the tree pruned and we let
users who need old versions extract them from viewcvs.

Best,
g2boojum
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Dylan Carlson]

On Friday 02 July 2004 10:41 am, Grant Goodyear wrote:
> I'm probably missing something obvious, but even reading the original
> bug report leaves me confused as to how a lack of stable mm-sources
> ebuilds is breaking systems.  Once mm-sources is installed anything
> that needs a kernel tree should build just fine. 

I think the problem comes in is if you have done exhaustive testing against 
a specific profile, and subsequently want to deploy a series of new 
systems using that profile-- which worked at one time, but now is broken 
in one way or another because ebuilds were taken out of the tree.  This 
scenario is one of those "enterprise" problems, but one that I think could 
be solved through repoman checks.  Unless I'm completely mistaken about 
what's being discussed here.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Chris Gianelloni]

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

On Fri, 2004-07-02 at 11:15, Dylan Carlson wrote:
> I think the problem comes in is if you have done exhaustive testing against 
> a specific profile, and subsequently want to deploy a series of new 
> systems using that profile-- which worked at one time, but now is broken 
> in one way or another because ebuilds were taken out of the tree.  This 
> scenario is one of those "enterprise" problems, but one that I think could 
> be solved through repoman checks.  Unless I'm completely mistaken about 
> what's being discussed here.

While I can definitely see this position, nobody should consider Gentoo
to be 100% enterprise friendly without some leg work on the part of the
admin.  A "tested profile" would also have to include specific versions,
otherwise there is no way that a person could properly certify the
validity of the test.  The only way to ensure a stable (as in
non-moving) tree is to maintain a local tree, or to *never* sync.  In
both cases, the actions of the Gentoo development team should have
absolutely zero impact on the user.

We understand that this is a limitation of Gentoo, which is why a GLEP
was drafted for the "stable" tree and also why there is a group of
people working to bring "Enterprise Gentoo" to fruition.  Right now we
have no simple answer, other than for the administrator to be vigilant. 
After all, simply running an emerge sync and updating packages without
certifying each one is definitely not "enterprise" policy at any large
outfit.  No amount of repoman checking will solve this, as it is more of
a infrastructure problem than a technical one.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Dylan Carlson]

On Friday 02 July 2004 4:29 pm, Chris Gianelloni wrote:
> A "tested profile" would also have to include specific versions,
> otherwise there is no way that a person could properly certify the
> validity of the test.

I agree.  The profiles only list ~70 packages and those versions aren't 
pinned.  Although maybe they should be.  The difference between the 
versions in a tested configuration/profile and what ends up getting 
installed later should include security updates (backported security 
fixes) -- which is not something we do right now...

My point is that I believe we could address this (at least in part) by 
pinning versions in profiles, and having repoman block commits that 
attempt to remove ebuilds that are required by a profile.  It's not a new 
idea.   This, instead of branching CVS.   Although I'm not opposed to that 
idea either, but IIRC some devs are...

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Chris Gianelloni]

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

On Fri, 2004-07-02 at 17:06, Dylan Carlson wrote:
> On Friday 02 July 2004 4:29 pm, Chris Gianelloni wrote:
> > A "tested profile" would also have to include specific versions,
> > otherwise there is no way that a person could properly certify the
> > validity of the test.
> 
> I agree.  The profiles only list ~70 packages and those versions aren't 
> pinned.  Although maybe they should be.  The difference between the 
> versions in a tested configuration/profile and what ends up getting 
> installed later should include security updates (backported security 
> fixes) -- which is not something we do right now...

...and I doubt that we ever will.  Gentoo tries to remain as much like
the upstream packages as possible, which means we're more likely to
require an upgrade than to back-port a patch.  This is the exact reason
why any plans for an enterprise version of Gentoo all focus on being a
separate project from Gentoo proper.  I know for a fact that I don't
want to waste the precious development time that I have doing the
mundane task of back-porting patches to some old version of a package
that I've long since forgotten.

> My point is that I believe we could address this (at least in part) by 
> pinning versions in profiles, and having repoman block commits that 
> attempt to remove ebuilds that are required by a profile.  It's not a new 
> idea.   This, instead of branching CVS.   Although I'm not opposed to that 
> idea either, but IIRC some devs are...

Pinning versions in the profiles sounds pretty cool, but it turns
*every* package maintainer and arch maintainer into a profile
maintainer, which I think is a bad idea.  It also bloats the portage
tree, since there would be multiple versions of every ebuild, compared
to the one or two for most packages that we have now.  I still think
that the "pinned" tree should be a separate branch.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Dylan Carlson]

On Friday 02 July 2004 5:37 pm, Chris Gianelloni wrote:
> Pinning versions in the profiles sounds pretty cool, but it turns
> *every* package maintainer and arch maintainer into a profile
> maintainer, which I think is a bad idea.  It also bloats the portage
> tree, since there would be multiple versions of every ebuild, compared
> to the one or two for most packages that we have now.  I still think
> that the "pinned" tree should be a separate branch.

It wouldn't turn everyone into profile maintainers -- it would just ensure 
that no ebuild gets removed accidentally that is required by a profile, by 
repoman's QA check.  If that ebuild *needs* to be removed for any reason 
(let's say a vulnerability) then it would be up to the arch herds to 
update their profile(s) accordingly -- not up to the herd/maintainer of 
the package.

The CVS branching / Gentoo Enterprise idea (to me) sounds overengineered.  
I haven't done a survey of IT managers to see what their expectations are, 
but in my 14 years, management, etc -- I know what /my/ basic requirements 
are.

1/ Conservative defaults
2/ A regular, predictable release schedule 
3/ Packages are not updated between releases, except in cases of 
vulnerabilities or major bugfixes
4/ In the event of #3, basic regression testing before the changes are 
committed
5/ Supporting documentation & tools geared towards enterprise deployment

I would agree that it's more elegant and ideal to have them maintained 
independently.  Yet, it's easier for a commercial entity like, say, RedHat 
to offer Enterprise on one hand, and then Fedora on the other, as separate 
branches of development.  They've got a consistent revenue stream and a 
sizeable staff of paid developers & support techs who clock in 40-50 
hrs/wk guiding both products.   Given the flux nature of volunteer 
developers I'm not positive we can live up to those same expectations if 
we attempt to maintain two separate trees.

However we can get the job done with repoman, some developer/QA policy 
tweaks, and pinning packages in profiles.  It seems to be a simpler 
solution, and we don't need to segregate the dev pool to do it.   People 
can contribute to both sides if they know what the rules of engagement 
are.

I'm sure we have intelligent people working on this; this is just my take.  
Simpler solutions tend to work better for free projects.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Marius Mauch]

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

On 07/03/04  Dylan Carlson wrote:

> On Friday 02 July 2004 5:37 pm, Chris Gianelloni wrote:
> > Pinning versions in the profiles sounds pretty cool, but it turns
> > *every* package maintainer and arch maintainer into a profile
> > maintainer, which I think is a bad idea.  It also bloats the portage
> > tree, since there would be multiple versions of every ebuild,
> > compared to the one or two for most packages that we have now.  I
> > still think that the "pinned" tree should be a separate branch.
> 
> It wouldn't turn everyone into profile maintainers -- it would just
> ensure that no ebuild gets removed accidentally that is required by a
> profile, by repoman's QA check.  If that ebuild *needs* to be removed
> for any reason (let's say a vulnerability) then it would be up to the
> arch herds to update their profile(s) accordingly -- not up to the
> herd/maintainer of the package.

One major problem with version pinning in the profiles is that the
packages file is an *inclusion* mask, so if you specify one exact
version portage won't allow users to use any other version of that
package. I don't think that we want to force specific versions on users.
If we do so they will start to modify the profiles locally which would
be an even worse problem.
I could also imagine some problems related to the current implementation
of stacked profiles, but that's implementation specific.
If you only want a repoman check I'd rather recommend to introduce a new
file that contains names and versions of packages that have to be in the
tree for that profile, but anyway this needs a GLEP before it could be
considered.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Dylan Carlson]

On Sunday 04 July 2004 6:10 pm, Marius Mauch wrote:

> I don't think that we want to force specific versions on users.
> If we do so they will start to modify the profiles locally which would
> be an even worse problem.

For current releases/profiles, I would agree.  For old profiles, I think 
it's reasonable to restrict packages.  It's easier to keep a profile 
together than it is to support the whole package tree against users who 
are using a 1.0 profile (or whatever).  I'm not sure it's possible for us 
to adequately QA old profiles -- moving targets.   It makes sense (in my 
way of thinking, anyway) to limit old profiles to things we know that 
work... things that are thoroughly tested against that profile.  While the 
majority of our manhours happen in the current and future profiles.   If 
people need newer packages, they would consider switching their machines 
to a newer profile.

> anyway this needs a GLEP before it could be considered.

Agreed.  I'm not part of the "enterprise" stuff, wherever that currently 
lives (it's not listed in Projects or Sub-projects, so I have no idea).  
But I would like to be a reviewer in that process at least, if not a 
contributor.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Barry Shaw]

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

It looks like there are two separate issues here, packages in the
profiles being removed and an enterprise gentoo.  I'm mainly concerned
at the moment about pinned package versions in the profiles being
dropped out of portage which would break any machine build based on that
profile.

Given that in the 1.4 and 2004.0 profiles there is only one pinned
package, it doesn't look like a major - its probably something that just
~ the maintainer for that package should be aware of (some automated
check as previously mentioned would be a good safety net).  If there
were no pinned packages in the profiles, then as long as the cat-pkg
names didn't change, the profile would exist indefinitely with little
effort on any devs part.

Now I'm not suggesting that profiles should be kept forever, but if they
are made redundant with little or no notice, it can cause big problems
if you've got hundreds of machines installed with that profile.

That said, I think an enterprise gentoo is a good idea, but its not
something that the devs should be lumbered with on top of maintaining
ebuilds.  It sounds like there is more than enough to do already 8).
Can anyone point me in the direction of the people involved in
enterprise gentoo?  We've got about 250 machines currently gentooed,
with more to come, so we might be able to offer some insights into large
scale installations.

|
| The CVS branching / Gentoo Enterprise idea (to me) sounds
overengineered.
| I haven't done a survey of IT managers to see what their expectations
are,
| but in my 14 years, management, etc -- I know what /my/ basic
requirements
| are.
|
| 1/ Conservative defaults
| 2/ A regular, predictable release schedule
| 3/ Packages are not updated between releases, except in cases of
| vulnerabilities or major bugfixes
| 4/ In the event of #3, basic regression testing before the changes are
| committed
| 5/ Supporting documentation & tools geared towards enterprise deployment
|

I agree, if we can get a enterprise framework that exists within most of
the current gentoo infrastructure, that means less work for everyone,
and therefore a higher chance of a sustainable project.

A stable portage tree would be the single most useful thing here.  We
only re-sync our portage copy when security vulnerabilities are
announced, but due to the dynamic nature of the portage tree, this often
means upgrading lots of other packages in the process (e.g. mozilla 1.7
breaks epiphany which means a gnome 2.4 to 2.6 upgrade for us.  Not a
big deal, but something that needs to be communicated to users before hand).

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

iD8DBQFA6IG1JvZkjpKMF2wRAg0fAJ9BvwBrb7uAT3sHknaOoTkffdpDWACgs5rk
1q7Zv3coQQhnddHAD7Ei8vA=
=LQ7G
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Dylan Carlson]

On Sunday 04 July 2004 6:16 pm, Barry Shaw wrote:
> We've got about 250 machines currently gentooed,
> with more to come, so we might be able to offer some insights into large
> scale installations.

Very nice.   Yes, I would love to know more about how you're using Gentoo 
commercially.

In the past, I've done some production installs of FreeBSD with success, 
but not w/Linux yet.   A Gentoo deployment should be more controllable, in 
my estimation, than FreeBSD, but there's a lot of work to be done on both 
to make them more sane for commercial environments.  IMO, the first 
priority is just minimizing the rate/amt of change.  That's half the 
battle.   IT folks can't be burdened with the minutae of researching & 
testing lots of tiny little package updates.  

The "don't rsync" solution is a kludge... we need something a tad more 
thoughtful, functional than that.  :-)

If you don't mind my asking, how many of your Gentoo machines are 
workstations?  Servers?  What kind of work is done on these machines?

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Barry Shaw]

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

Dylan Carlson wrote:
| On Sunday 04 July 2004 6:16 pm, Barry Shaw wrote:
|
|>We've got about 250 machines currently gentooed,
|>with more to come, so we might be able to offer some insights into large
|>scale installations.
|
|
| Very nice.   Yes, I would love to know more about how you're using Gentoo
| commercially.
|

Well we're a university, so we aren't commercial as such 8).  All of the
machines are being installed via a custom script and a binary repository
that is used as a canonical source of packages.  Additions and removals
are performed automatically each night on the clients.  We've documented
the install process at http://www.scms.waikato.ac.nz/~baz and the
scripts are available there also.  The nightly maintenance process and
scripts aren't yet published but its in the works.  If you want a more
detailed description let me know and I can send you something offlist
(I'm not really sure this list is the right place for this kind of thing).

| In the past, I've done some production installs of FreeBSD with success,
| but not w/Linux yet.   A Gentoo deployment should be more
controllable, in
| my estimation, than FreeBSD, but there's a lot of work to be done on both
| to make them more sane for commercial environments.  IMO, the first
| priority is just minimizing the rate/amt of change.  That's half the
| battle.   IT folks can't be burdened with the minutae of researching &
| testing lots of tiny little package updates.
|
| The "don't rsync" solution is a kludge... we need something a tad more
| thoughtful, functional than that.  :-)
|

Definitely, thats where I see a stable portage tree as being very useful.

| If you don't mind my asking, how many of your Gentoo machines are
| workstations?  Servers?  What kind of work is done on these machines?
|

Most of them are workstations, both lab machines and staff and graduate
desktops (they are all maintained in a similar fashion).  We've only got
a few gentoo servers, mainly since we only started using gentoo here
less than 6 months ago and we're only upgrading the servers as they are
replaced (if it aint broke.....).

Baz



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

iD8DBQFA6LqaJvZkjpKMF2wRAkNVAKCKd88s/qUPlQPTquiCsS1VhJNJ7gCfUzHH
IR/4zWK9bMVyWcBLw9OtGrA=
=LYLd
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policy for retirement of old gentoo 'versions'

[Chris Gianelloni]

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

On Fri, 2004-07-02 at 09:44, William Kenworthy wrote:
> A few weeks back I filed a bug (since closed, but not resolved to my
> satisfaction) on the premature removal of mm-sources and the fact that
> no stable version was left in portage.  This had the effect of breaking
> a number of perfectly working systems and leaving no alternative but to
> move to another kernel as the masked versions did not work (at the time)
> - a major hassle.  Without a kernel of that package in portage, packages
> that depended on the installed kernel to build broke and couldnt be
> installed.

Unless there was a security problem, then there should always be a
stable version in portage once any version has ever become stable.  This
specific incident was not what is supposed to happen.

> I for one would like to see a policy for this as I feel that mm-sources
> was done at the whim of a dev who was looking at his future, and wasnt
> willing to consider the user base, leaving quite a number of us
> stranded.  His justification seemed to be that mm-sources should be
> considered a dev package, so I should not have bothered - bug closed.

You won't see a policy for this any time soon, as different packages
have different needs, and we don't have the man power to back port to
known broken releases just because of some arbitrary policy.

With that being said, your example had absolutely nothing to do with
such a policy, but rather with a policy that does exist to never remove
all stable versions of a package from portage without moving one of the
testing packages to stable.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]