On Saturday 21 January 2006 22:39, Marius Mauch wrote: > Check the archives for gentoo-dev and gentoo-server, several > implementation plans have been presented in the not-so-distant past. > However everyone seems to have a slightly different goal he wants to > achieve, so maybe the best would be for people to make their goals very > clear.
I have checked the archives of gentoo-dev, gentoo-server, and have
researched everything I can find about glep 19. I have come to the
conclusion that those "projects" are the /dev/null of gentoo projects.
Post a request somewhere - "hey, check out glep 19, wink wink".
Let me make my goal clear. I would like to see some simple features added
that does not require disruption of current usage, future plans, or require
massive changes. I am not interested in reviving dead projects or loft
goals.
> No point, would rather add a RSYNC_OPTS var finally instead, which gives
> the same functionality (and much more).
If that would work, great. Not sure how rsync handles ordering/precedence
of conflicting options, now or in the future. Also not sure how the
environment may or may not be manipulated in the future by emerge itself.
Right now the options are hard-coded into emerge, the simplest place to
change it in my mind is right there where it happens...
> > 2) Implement a new revision numbering scheme for ebuilds, -sX. Similar
> > to -rX, but for glsa updates only. It could be an abbreviation for
> > sticky, security, or stable, whatever you want.
> >
> > For example if I am currently running mysql-4.0.25, the only candidate
> > an emerge -u would consider would be mysql-4.0.25-s1, mysql-4.0.25-s2,
> > etc.... In other words, emerge considers only -sX in its upgrade
> > calculations, instead of -rX, and only considers the same version.
>
> No way. No visible benefit (you know about glep 14 / glsacheck, right?)
> and tons of issues (redundant ebuilds, ordering screwups, ...)
Yes, I am aware of glsacheck. How long has it been in testing? Every time
I try it I get inconsistent results. Something about "WARNING: This tool
is completely new and not very tested, so it should not be
used on production systems. " kind of makes me hesitate to use it.
As far as redundant ebuilds and ordering screwups. If you change line 3173
of portage.py to:
if len(myrev) and myrev[0] in ["r","s"]:
Everything works quite well actually. The s is sorted after the r, so -s7
would install after -r6 or instead of -r7. It is actually a much simpler
solution than glsa, could be introduced immediately to the portage tree,
and use of it could be optional. People could use them in their own
overlays, backport their own security fixes.
> No chance you get people to agree on something that will bloat the tree
> without any real benefit. Mind that we already revbump packages for
> security updates.
Packages are not only revbumped for security updates. I have not researched
it much, but I would be willing to be the vast majority of revbumps are
_rarely_ for security updates. Most of the time glsas suggest to bump up
to the next version of the package, not revision... There is also no way
to distinguish between a revbump that alters the package via a revbump that
is only because a glibc has just been marked stable for another
architecture, for example.
> No, this includes way too many changes to core functions (version
> comparison, resolver) with no visible benefit (from my POV). In case you
> haven't done so already take a good look at glep 14 and glsa-check
> (which implements the least-invasive update algorithm you seem to be
> after).
I am happy to see that you state that the "no visible benefit" is limited to
your POV. Glep 14 (glsa-check) is a fine idea, a fine proposal. The only
problem is that it appears as though it is never going to happen, at least
not the final goal - to get integrated into portage.
I like my idea better. It is a very simple change that could be introduced
immediately with little or no ill effect. Functionally, that one line
patch I posted above would work as far as I can tell. It instantly creates
a framework for backporting security fixes (without affecting current
usage), glsa does not. GLSA updates would then become a fairly simple
matter - emerge -Du world, filter out all non -sX packages. Extend the
idea further and people who desire could filter syncs to just retrieve
*-sX.ebuild and your load on the mirrors has just lightened, not grown..
pgpIrZttezczC.pgp
Description: PGP signature
