[gentoo-dev] Request for Comment

[gentoo-dev] Request for Comment

[Klaus-J. Wolf]

Hi,

I am new to this list, but I am not new to Gentoo.

Would you please discuss a GLEP draft, which I believe it might improve 
the usability of Gentoo?

Text at:

http://www.seismic.de/gentoo/gentoo_mask_proposal.html

Technical details still missing...

Regards
k.j.



ps. I can also post the text, it just doesn't look very pretty when 
reformatted...
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Request for Comment

[Dan Meltzer]

On 2/10/06, Klaus-J. Wolf <yanestra@seismic.de> wrote:
> Hi,
>
> I am new to this list, but I am not new to Gentoo.
>
> Would you please discuss a GLEP draft, which I believe it might improve
> the usability of Gentoo?
>
> Text at:
>
> http://www.seismic.de/gentoo/gentoo_mask_proposal.html

Seems like a huge amount of work for a little amount of benefit..

There is no need for 10 versions of a package, it only serves to
create more maintainence problems.
>
> Technical details still missing...
>
> Regards
> k.j.
>
>
>
> ps. I can also post the text, it just doesn't look very pretty when
> reformatted...
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Request for Comment

[Duncan]

Klaus-J. Wolf posted <200602110337.25218.yanestra@seismic.de>, excerpted
below,  on Sat, 11 Feb 2006 03:37:25 +0100:

> Would you please discuss a GLEP draft, which I believe it might improve 
> the usability of Gentoo?
> 
> Text at:
> 
> http://www.seismic.de/gentoo/gentoo_mask_proposal.html

I'm just a user, not a dev, myself, so take this as you will, but the
general idea is the same sort of ultra-stable enterprise stability
targeted system that comes up for discussion here every so often, and
already has various levels of workable and not-quite-so-workable proposals
floating around.  This particular one's in the not-quite-so-workable camp,
mainly because  (1) it doesn't work /with/ portage or the way things work
now, but against it, in a number of ways (2) it doesn't consider the
different speeds at which different packages move (this is the big one,
there's likely never /been/ ten or even five versions of some packages
that have existed since there /was/ a Gentoo), and (3) it doesn't really
consider the way devs work.  Point of fact, it's particularly from a user
perspective, not understanding a /lot/ about the "supply" side of the
distribution mechanism, only the /user/ or /demand/ side.

I'm specifically /not/ saying I could do better, but... take a look at the
archives for this list, read some of the previous proposals and the
discussion they generated, and /then/ formulate a proposal, based on what
has been already hashed out and found /not/ to work, vs what there's been
little disagreement about, only it just hasn't been fully implemented, yet.

As for specifics...  Most of the issues you mention are already addressed
with the current system, or aren't practically addressable anyway, with
your proposal either asking the impossible (ten versions of something
there may have only been two or three releases of in the entire time
Gentoo has been around), or not directly addressing the problem in the
first place) what works for most systems will inevitably fail in some
corner case, which will either never be traced, or ends up being related
either to a specific mix of packages, or to a specific configuration at
the problem side -- one not tested for as it has never occurred to anyone
in the pre-stable release period, because nobody matched those conditions.
This is, BTW, exactly the same reason that invariably, a new kernel
release brings a new round of bugs that weren't caught in the rc and
pre-release testing -- no one had that specific configuration to test on
-- so it's not just a Gentoo issue.  BTW, it's also not an open source
issue, as the service-pack releases attest in the proprietary market --
and they get /paid/ to make sure it works.

There's actually three levels of masking, four if you include being
available in an overlay on someone's dev-space somewhere but not yet in
the tree as a sort of super-masked state, in addition to the unmasked
state, and one of the recent Enterprise Gentoo proposals suggested a
fourth/fifth, a +arch (super-stable), tho that hasn't yet been
implemented, and may or may not ever get to that point.

The current levels:

* (not yet in the tree)

* In the tree, with no keywords, or more precisely -*.  This signifies a
"work in progress" not yet considered by the Gentoo maintainer to be ready
for significant deployment, even at a testing level.  Some of these are
there by popular demand for the convenience of the users and will /never/
get further, nor are they considered supported by Gentoo. Certain periodic
CVS snapshots can fall into this category.  These are often packages that
are considered unstable/testing/alpha/beta, non-release quality, upstream,
as well.

* Hard-masked.  These ebuilds normally appear in the package.masked file
at the base of the profiles tree, with a reason given there as to why they
are in this hard-masked state.  It can range from pre-release upstream
versions of a package that will ultimately have a stable release (the
snapshots/betas/rcs of xorg-modular and GNOME and KDE come to mind), to
packages masked before removal due to security issues or because they
simply no longer work in a changing world, and upstream is abandoned, so
no new versions are appearing (the GLSA announced packages, and the "Last
rites for <pkg> announcements here on this list, signify packages normally
hard-masked, then removed).

* ~arch masked as candidate for stable.  ~arch, where arch can be x86,
amd64, ppc, etc, indicates a package normally considered stable or at
least release candidate level upstream, where the ebuild /should/ work for
/most/ Gentoo users as is, and there are no known dangerous bugs left. 
These are candidates for going stable, after some period of testing in
~arch with no bugs.  Note that the archs themselves (save for x86 until
recently) ultimately determine when and whether a package goes stable, and
the maintainer usually signals his willingness for this to happen by
stabilizing on his own arch(s) when he feels comfortable doing so. 
There's no hard and fast rule for when something goes stable, but the
general rule of thumb is after 30 days in ~arch and with no open bugs. 
Thus, ~arch indicates a package considered stable upstream, and ready for
testing to be stable on Gentoo.  The package should be stable, but the
ebuild, the way the package interacts with Gentoo specifically, might not
be, is another way to put it.

The problem you apparently had, was that you apparently did the equivalent
of adding the package in question to /etc/portage/package.unmask and/or
/etc/portage/package.keywords, with the appropriate ~arch keyword,
without confining it to a specific version.  It has been possible since
portage 2.0.51 at least to make such a listing apply to a specific
version, such that no others will be unmasked.  If you want to apply it to
all versions of the package, running the  latest ~arch keyworded version
of the package for your arch rather than the latest stable version, that's
possible, and what you apparently did, by simply leaving out or
wildcarding the version specifier, but if you want only a specific
version, that too is possible, and has been for some time, and should have
been what you did, if you were in doubt about future ~arch versions.

The point is, you don't /have/ to monitor your manually unmasked ebuilds,
as if the version is properly specified, portage won't upgrade you
automatically in any case.  Thus, that can't be justification for changes
to the current system, as that feature is already available, and indeed,
widely used as intended.

As mentioned, your proposal is unworkable  in present form anyway (not a
big deal, no GLEP would be at this stage), because there simply haven't
been ten versions available of many packages, and of the ones where there
have been, there are very very seldom ten package versions still workable
on a current system, for any given arch.

As briefly mentioned above, there /has/, however, been a proposal for a
"super-stable" package marker, +arch.  This package would likely no longer
be maintained by the regular Gentoo maintainer, as backporting security
changes and the like to something that old is something many maintainers
would resist, preferring instead to simply remove the vulnerable or
unworkable package from the tree.  Rather, the new Gentoo Enterprise
project, presumably containing devs interested in the often dreary work of
backporting and maintenance of an Enterprise-stable distribution, would
maintain these builds.  The fact is, there are a number of devs intensely
interested in such a program, to the point they've been known to complain
about Gentoo having no visible progress, because this one thing they are
so interested in hasn't occurred.  However, apparently, these devs either
don't have /enough/ interest, or don't have /enough/ time (they are,
after all, volunteers), or there simply aren't /enough/ such devs, or more
likely a mixture of the above, for this to have been seen thru to
completion at this point.  The idea of an Enterprise Gentoo that supports
packages well past the time when they are no longer viable in the standard
Gentoo portage tree, remains just that, an idea, at this point.  There has
been work done on it, but you'll have to pull the archives and look up the
devs supporting the idea, to see what the current status is.

So... what it all comes down to, if you are seriously interested in
something along these lines, is checking the list archives to see what
past proposals have been, their strengths and the elements of them that
were shot down, and the people pushing them, then contacting them, to see
what you can contribute toward bringing such a proposal to pass.  Don't go
away if you are serious about changes and willing to contribute to see
them accomplished -- Gentoo /needs/ folks like you that are interested,
but do some research and get in contact with the devs with similar
interests, and see what you can do, then as part of /that/ group, come
back when the proposal is ready for further discussion, having addressed
the known issues as much as possible, and possibly to be adopted.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Request for Comment

[Simon Stelling]

(I think it would be better if you could post the text on the list, so people
can easier cite the paragraphs they are referring to.)

> I cite one situation which has actually led to system destruction:
>
> I was in need of a certain version of a library. A the moment I installed it
> initially, this version was keyword masked for my architecture, since it was
> not thoroughly tested. It worked perfectly anyway. Since it was without
> issues, it became officially unmasked some time later and another version was
> introduced, which was keyword masked because it didn't work at all on my
> architecture. This one could be compiled, but really didn't work at all. Since
> I didn't observe the new version introductions all the time, a slightly
> careless world update gave me that version and left all programs depending on
> the library in a non-working state.
>
> After all it was my fault, but on a resonably maintained system you will
> always have a number of manually unmasked ebuilds, and you can't monitor them
> all the time.

This is why you should use exact versions in p.mask and p.unmask. If you do that
you only get the minimum of masked packages, leading to minimal borkage.

Now, over to the GLEP draft..

You make some very dangerous (partly wrong) assumptions in your GLEP. First of
all, there's the assumption that we have the capacity to maintain such a fine
graded masking scheme. We are currently mainly distinguishing between testing
~arch and stable arch. I can only speak for AMD64, but we have a currently ~100
packages that wait to go into the ~amd64 tree, 54 of them for longer than 30
days. Beside that, we have about 120 packages waiting to go into the stable
tree. Now, if you'd increase the number of masking "stages" from two to 10, I
can guarantee that this masking scheme would get completely useless.

But the far more critical assumption you make is this one:
You assume that once a package has been marked stable, it keeps beeing stable.
You simply can't treat every package individually. A package marked stable back
in 2004 with a status level -5 should be considered ultimatively stable if I
understand your proposal right. But then GCC 3.4 is marked stable too, and, oh,
look, it doesn't even compile!? Things depend on each other, in a very complex
fashion. Whenever some behaviour in one package is changed, it is likely to
break another one. Instead of giving us 10 different status levels, show us a
way to avoid such problems in general.

Part of the assumption above is also the fact that these keywords do not
consider the profile the user is using. A package might work great for one
profile but terribly break for another (deprecated) one.

You can apply the same idea to eclasses. Basically it all bails down to this:

Give me 10 environments and I give you 10 different ways to break the package.

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Request for Comment

[Marius Mauch]

Klaus-J. Wolf wrote:
> Hi,
> 
> I am new to this list, but I am not new to Gentoo.
> 
> Would you please discuss a GLEP draft, which I believe it might improve 
> the usability of Gentoo?
> 
> Text at:
> 
> http://www.seismic.de/gentoo/gentoo_mask_proposal.html
> 
> Technical details still missing...

Ignoring the huge maintenance issues already stated there are also 
technical reasons speaking against this. First adding another file in 
every package dir would bloat the tree considerably (estimate about 50 
MB diskspace on "normal" filesystems). Second separting the metadata 
from the ebuilds has major implications on portage (need a new parser, 
API changes in core functions, complete change of semantics).
And finally of course there is this minor issue called transition.
So short version: no chance.

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Request for Comment

[John Mylchreest]

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

On Fri, Feb 10, 2006 at 10:41:04PM -0700, Duncan <1i5t5.duncan@cox.net> wrote:
> Klaus-J. Wolf posted <200602110337.25218.yanestra@seismic.de>, excerpted
> below,  on Sat, 11 Feb 2006 03:37:25 +0100:
> 
> > Would you please discuss a GLEP draft, which I believe it might improve 
> > the usability of Gentoo?
> > 
> > Text at:
> > 
> > http://www.seismic.de/gentoo/gentoo_mask_proposal.html
> 
> I'm just a user, not a dev, myself, so take this as you will, but the
> general idea is the same sort of ultra-stable enterprise stability
> targeted system that comes up for discussion here every so often, and
> already has various levels of workable and not-quite-so-workable proposals
> floating around.  This particular one's in the not-quite-so-workable camp,
> mainly because  (1) it doesn't work /with/ portage or the way things work
> now, but against it, in a number of ways (2) it doesn't consider the
> different speeds at which different packages move (this is the big one,
> there's likely never /been/ ten or even five versions of some packages
> that have existed since there /was/ a Gentoo), and (3) it doesn't really
> consider the way devs work.  Point of fact, it's particularly from a user
> perspective, not understanding a /lot/ about the "supply" side of the
> distribution mechanism, only the /user/ or /demand/ side.

Duncan, you make some valid points but for the sake of ease for the rest
of us, could you please try condense the mails down from several pages? :)

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


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

[gentoo-dev] Re: Re: Request for Comment

[Duncan]

John Mylchreest posted <20060211170258.GB874@getafix.willow.local>,
excerpted below,  on Sat, 11 Feb 2006 17:02:58 +0000:

> Duncan, you make some valid points but for the sake of ease for the rest
> of us, could you please try condense the mails down from several pages? :)

I've been proud of myself, even managing a couple one-liners, lately. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Re: Request for Comment

[John Mylchreest]

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

On Sat, Feb 11, 2006 at 11:09:07AM -0700, Duncan <1i5t5.duncan@cox.net> wrote:
> > Duncan, you make some valid points but for the sake of ease for the rest
> > of us, could you please try condense the mails down from several pages? :)
> 
> I've been proud of myself, even managing a couple one-liners, lately. =8^)

Keep up the excellent work ;)

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


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

Re: [gentoo-dev] Request for Comment

[Benno Schulenberg]

Klaus-J. Wolf wrote:
> http://www.seismic.de/gentoo/gentoo_mask_proposal.html
> 
>   * Manually keyword unmasking an ebuild, automatically means 
>     unmasking the last one in the line of masked versions. 

No.  Use the "=" to unmask a specific version only.  For example:

=sys-apps/findutils-4.2.25  ~x86

Benno
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Request for Comment

[Ciaran McCreesh]

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

On Sun, 12 Feb 2006 00:11:07 +0100 Benno Schulenberg
<benno@nietvergeten.nl> wrote:
| Klaus-J. Wolf wrote:
| > http://www.seismic.de/gentoo/gentoo_mask_proposal.html
| > 
| >   * Manually keyword unmasking an ebuild, automatically means 
| >     unmasking the last one in the line of masked versions. 
| 
| No.  Use the "=" to unmask a specific version only.  For example:
| 
| =sys-apps/findutils-4.2.25  ~x86

Usually better to use ~, so that you pick up any revbumps.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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