On Friday 21 January 2005 04:25, Daniel Goller wrote:
> The case for versioned eclasses
> ===============================
>
> * We want a reproducable system
Yes we do. As eclasses already have to be committed to CVS, this is already
achieved.
> . 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.
cvs diff is your friend here. The sort of versioned eclasses you are asking
for add no value here to devs.
> 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.
eclasses have nothing to do with profiles. (And yes, I'm deliberately
mis-understanding you here)
> * When an eclass upgrade causes problems it is at the moment pretty much
> impossible to revert to an older versions.
An older version of what?
There's no guarantee that an older version of an eclass will work with the
latest ebuild. Allowing users to mix and match to suit will cause more
confusion in bug reports.
How will a user revert? How will a user decide that they need to revert? How
will they then pick up the fixed version of the eclass when that is released?
> 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".
The user already has several choices available.
1) Most importantly, they have the source. They can fix it and submit a patch
via bugzilla.
2) They can build binary packages, and revert back to the last package.
3) They can restore files from their regular backups.
Who goes around telling users to "read changelog, grab file from viewcvs, copy
to /usr/portage/eclasses, hope it works"? I want names please.
> * All files in portage should have checksums.
+1. But this is nothing to do with versioning. This is an integrity (sp?)
issue.
> Unversioned files will be very hard to track reliably.
Eclasses are already versioned - just not the way you want. We already modify
ebuilds successfully without renaming them - and they are checksumed. Even
if eclasses had version numbers in their name, it would be necessary at times
to change an eclass without giving it a new name.
> 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")
We change ebuilds sometimes without version bumps. It's expressly encouraged
under certain circumstances. Are you saying that this practice should also
change?
> The sample eclass exploit of aholler should have made all people
> involved aware of those issues
How many users run without the 'strict' FEATURE enabled? Our install stages
don't even ship with this switched on!
It's true that an eclass can be maliciously changed, and no-one would notice
until it is too late. Portage should support digests / signing of eclasses.
Have you asked Nick what he and his team are doing about this?
But this has nothing to do with "versioned" eclasses, and nothing you're
suggesting makes the blindest bit of difference to digest / signing eclasses.
> 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.
There's no reason to suggest a new version number scheme just for eclasses.
If Portage was to support version numbers for eclasses, they should follow the
same rules that ebuilds already do.
> - - Programs could depend on major, major-minor or (usually not desired)
> the full version string. the usual operators > / < / >= / <= / ! should
> be supported.
Again, there's no reason why this for eclasses should be any different to what
is already supported for ebuilds.
> - - eclasses should have a stable/unstable keyword. Users of a stable
> profile should not be forced to update to untested code :-)
Can be achieved through other means already. For example, we could have a
'php-sapi-stable.eclasss' and a 'php-sapi-unstable.eclass', and have the
ebuild inherit the right one. I agree that keywords would make things more
automated, but Portage is not stopping developers from achieving the same
results today.
> - - eclasses could use a symlink hierarchy like .so files:
> foo-1 --> foo-1.2 --> foo-1.2.43
Why do this? It's not necessary for ebuilds. Once again, it would make more
sense to make "versioned" eclasses to work the same way as ebuilds currently
do.
> inherit could then be handled quite easy.
It already is. The beauty of the existing inherit is that it gives eclass
authors all the freedom they need to do the right thing.
Portage does not *have* to change. It is the behaviour of developers that
needs to change. You cannot enforce behavioural change through technology.
> 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.
This breaks your rule of reproducability. You can have mix and match, or
reproducability, but not both. This is a basic SCM thing.
> Note: The implementation ideas are just that. Ideas. If you find some
> structural flaw in them, tell us, don't flame :-)
>
> wkr,
> bonsaikitten & morfic
I've read Alexander's bug (26110). It sounds like Alexander expects to be
able to mix ebuilds from one month and eclasses from a different month (for
example). Having different eclasses for different major versions of a
package (see the nxserver eclasses as an example of what can already be done)
solves his problem, and requires no code changes to Portage itself.
I don't understand why you are pursuing your current approach. You've trying
to connect unrelated problems together, ignoring what's possible today,
ignoring what's already done today, in order to push technically poor
solutions which wouldn't solve your problems anyway.
You've ignored good advice given in the previous thread, instead choosing to
try and push your original unmodified solution once more on this new thread.
Aren't you wasting everyone's time posting a suggestion to the list if you're
not going to listen to the responses?
You're suggesting a technical solution to a behavioural (sp?) problem. A
technical solution never solves behavioural problems. Look at everyone who
blames repoman for their own mistakes to see that demonstrated on a daily
basis ;-)
Have you thought about a different approach? Get the eclass howto updated to
say something along the lines that eclasses need a version suffix, and when
an eclass change breaks backwards compatibility, the eclass needs a rev bump.
It's short, sensible, needs no Portage changes, and you'd probably succeed in
getting it through without too much of a fight.
Eclass digests / signing (your bug 64258) is a completely unrelated issue.
Your vision of "versioned" eclass support doesn't make eclass digest /
signing any easier at all.
Best regards,
Stu
--
Stuart Herbert [EMAIL PROTECTED]
Gentoo Developer http://www.gentoo.org/
http://stu.gnqs.org/diary/
GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
--
--
gentoo-dev@gentoo.org mailing list
