-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The case for versioned eclasses ===============================
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 ;-)
* 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.
* 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".
* 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")
The sample eclass exploit of aholler should have made all people
involved aware of those issues
Implementation ideas: =====================
- - - Versioning could be of the form foo-2.1.43.eclass where the version number is parsed as major/minor/patchlevel. So foo-2.1.42 predates 2.1.43, but offers the same functions and only trivial fixes.
- - - Programs could depend on major, major-minor or (usually not desired) the full version string. the usual operators > / < / >= / <= / ! should be supported.
- - - eclasses should have a stable/unstable keyword. Users of a stable profile should not be forced to update to untested code :-)
- - - eclasses could use a symlink hierarchy like .so files: foo-1 --> foo-1.2 --> foo-1.2.43
inherit could then be handled quite easy. Also, if a program (let's call it eclass-config) were created, the user could select which eclasses to use, thus making recovery from bugs a lot easier.
Note: The implementation ideas are just that. Ideas. If you find some structural flaw in them, tell us, don't flame :-)
wkr, bonsaikitten & morfic
further reading: http://bugs.gentoo.org/show_bug.cgi?id=64258 http://bugs.gentoo.org/show_bug.cgi?id=26110 - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFB74ltqER3hOUoZM4RAt7iAJ9qwIyMcvCTlnHY2qZ4w/r/orjzeQCfbAcs 6i2m1PaeJLltz7Q5HvrbI4M= =XKbK - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFB8IQLUpKYMelfdYERAnVCAJoCDnWTEtqT5wMyf86WkzZyheF7nQCeJzWm yACzggea9JWnwEO8jBrT25Q= =+rSz -----END PGP SIGNATURE-----
signature.asc
Description: OpenPGP digital signature
