On Thu, 20 Jan 2005 22:25:55 -0600 Daniel Goller <[EMAIL PROTECTED]> wrote: | Since the last few discussions ended in a flamewar, we'll try to | present our arguments with some comments and some ideas on | implementation. Please don't go "Booo hiss eeeevil!" now. That gets | boring after a time ;-)
Ok. It'd probably help if you two let everyone know which eclasses you
work with on a regular basis so that we can figure out how this
relates... The problems you describe don't seem relevant to any of the
eclasses I work with, but maybe the ones you use are different.
| * We want a reproducable system. Arbitrary changes to eclasses change
| the behaviour of core components and make testing and validation a lot
| harder to do. With versioned eclasses every change is visible. If your
| "profile" is locked, you will continue with an old eclass. If you want
| new and bleeding edge, you get the new and hopefully improved eclass.
It's already entirely possible to do eclass changes only for certain
versions of a package. Several eclasses do this already. Remember that
eclasses aren't supposed to be used for version-specific things, so the
only time the certain versions thing applies is when there're relatively
small changes between versions, such that it's not worth not using an
eclass function.
If you *do* have huge changes between package versions -- say, for
example, pcp4 to pcp5 -- there's nothing to stop you from doing a
pcp.eclass and a pcp-5.eclass. No need for any portageisms there.
So... What specific problems do you have with your eclasses that can't
be solved using either numbered or version-dependent code? If it's
something versionator can't do yet, maybe it'd be easier to add support
in there than doing huge changes to portage.
| * When an eclass upgrade causes problems it is at the moment pretty
| much impossible to revert to an older versions. Should some critical
| eclass not behave as expected the user should at least have some
| automation beyond "Read changelog, grab file from viewcvs, copy
| to /usr/portage/eclasses, hope it works".
This is why we test changes and do package-version-dependent code. The
situation's no worse than with ebuilds. If I make some huge changes to a
certain package and either remove all older versions or don't -r bump it
then the user is equally screwed. However, since I do testing and don't
apply eclass changes retroactively to older versions of packages, this
isn't an issue. The solution here is making sure developers really do
test things, not offloading proper QA into portage.
| * All files in portage should have checksums. Unversioned files will
| be very hard to track reliably. If every change in the file causes a
| version bump eclass integrity can be verified by the users without
| checksum consistency problems ("it was F5D123 yesterday, today it
| checksums to E47DDD, so it's been hacked")
Uhm... Checksums? We don't sign eclasses anyway just now, since portage
doesn't support it. For versioning, all eclasses should have a CVS
$Header$ line.
| The sample eclass exploit of aholler should have made all people
| involved aware of those issues
Just as easy to sign one eclass as it is to sign dozens of versions of
an eclass. Your argument here is completely bogus and suggests that
you're either trying to pass this off by sneaky underhand 'security!'
tactics or that you don't have a clue what you're talking about.
Hint: not all of us run around like headless chickens whenever anyone
says the word 'security'. This might work for some people but those of
us who have experienced the Weeve know better.
I'm not going to comment on all the problems I see in your proposed
implementation for now. Once the design is clarified I'll provide some
feedback, but for now I don't think it's worth considering given the
flakiness of the premises...
--
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail : ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
pgpRtT1xIiTLn.pgp
Description: PGP signature
