since we can change an eclass after it was used on a system chancxes are he can not reproduce the same result twiceOn 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.
it isnt always just about the value to us devs, we do have users, our customers, albeit the value for devs becomes more and more clear. 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.
as a dev who does not catch a problem affects less number of users if he at least bumped the eclass and used it only in a bumped version of the ebuild
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)
if you have a system and all packages are merged and you want to remerge it for whatever reason or upgrade to new version ebuild, you should be able to revert to the old ebuild version if the new doesnt work, as it is if the new version required changes in the eclass, there is no way for a user to revert to even the old ebuild version since emerge --sync took that away
* 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?
an older version of the eclass, since emerge --sync overwrote it
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.
no mixing and matching
old ebuild uses old eclass
new ebuild uses new eclass
new ebuild doesnt work, emerging of old ebuild using old eclass will allow reproduction of old package
by merging the old ebuild
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?
this is great for bugs not caught during thorough testing, it would afect any user of all versions of ebuild inheriting the same (single) eclass
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.
we can not control what they do, but we can control what we do once we are aware of a possible problem
3) They can restore files from their regular backups.
see 2)
for example sake, just tell me what other way a user has to revert to an eclass version other than what he currently has right now?
Who goes around telling users to "read changelog, grab file from viewcvs, copy to /usr/portage/eclasses, hope it works"? I want names please.
it could be defined what changes are allowed when to not compromise predictability
* 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.
It might require indeed an amendment to Gentoo policy that a rev bump to ebuild is required each time the eclass is bumped, to maintain repeatability of installs, and lay out if this is to be used only for system packages or globally, at this point i lean more towards globally
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?
some do, but instead of having to turn it off, what would be so bad to keep it on, and have those who actually are inconvenienced by it turn it off?
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.
We will involve them once the actual idea about how to do the versioning is brought along further, if they have input now we would appreciate their input, from looks of it versioned eclasses wouldnt involve any change to portage other than allowing digesting and signing them, but since we have no defenite solution i have nothing i can ask them to add digesting and signing for, but id like to ask them some time soon how difficult they think this would be
you forget something here, we will probably not need to follow the package versioning so we dont have to have it match what ebuilds do
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.
eclasses are actually our devs products, and if it is better to use a common practice in versioning for our product or tie them to the package version with -r is really not that big of a deal 2.1.43 is not reasonable but 2.1-r43 is? this is oked by me in a heartbeat, it was an example to name possibilities
If Portage was to support version numbers for eclasses, they should follow the same rules that ebuilds already do.
again the eclass could or could not be seen as its own product and we might ever only see foo-1.1 and foo-1.2 in the tree, while the foo package foo-1.1.5-r7 inherited foo-1.1.eclass while all versions of foo were fine since (and we are now still inheriting foo-1.2.eclass in foo-1.9.5 package)
and actually cut down on eclass bumps but this is just an idea
i dont think we want anything different for eclasses than we have for ebuilds
- - 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.
at ths point i lean more towards the suggested bumped eclasses through copying them to new versions, similar to bumps on 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.
it was an idea to throw out there and see if it gets picked up or not
brainstorming is about throwing out ideas and then picking those worth discussing
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.
they still have all the freedom if the inehrit foo-1.2 in one ebuild and foo-1.3 in the next, while giving the user the power to only merge those with foo-1.2 or in case of problems revert to the previous one he had which inherited foo-1.2
agreed, im aware of the fact my other thread was understood as "a lousy change to portage" which was never my intend
Portage does not *have* to change. It is the behaviour of developers that needs to change. You cannot enforce behavioural change through technology.
changing behaviours, amending policies, all can lead to the same goal
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.
the idea was related to the symlinks, while i at this point much more prefer the absolute inheritance of flat files with proper version
no we want:
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.
old ebuild uses old eclass and gives old result
new ebuild uses new eclass and gives new result if result good, kepp, if not revert to old ebuild and know what you get, not end up surprised to see the old ebuild wont merge you the same result cause the only eclass you got was what caused the breakage
again im not now and never was trying to push any kind of techonological solution, i used them as examples, just to have somethin to talk about
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?
this thread was started to cut the flaming and start the thread as it should have been started, the solution is presented in this way since the last thread dove too deep into "this solution is technically very poor" when it only looked like i was after only a technological tool mainly through poor wording i suppose on my part, i do not know how else it could haev been so drastically misunderstood
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 ;-)
again im not now and never was trying to push any kind of techonological solution, i used them as examples, just to have somethin to talk about
and i agree that behavioural (running here with your spelling) changes wil go hand in hand with other things once this comes to an end
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.
replies i received and suggestions made show how well flat files would work, a simple copying from old foo-1.2.eclass to new foo-1.3.eclass and then making changes would already cut down a lot on problems since only the new rev bumped ebuild would use foo-1.3 and the old ebuild using foo-1.2 would still work as they did before the bump to foo-1.3.eclass
use that together with johnm's suggestion for subdirs, and a amendment to ebuild rev bumping policy (to avoid "well i couldnt bump it, policy told me not to, sorry all those users had to pay the price, not my fault, i followed policy")
and id think more people could agree to it at this point already
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
Thank you for your email, if it hadn't helped for anything else, it at least shows how strongly misunderstood my use of a portage tool as an example was, it has taught me to start future threads differently and not use any technical examples if they arent meant to be a "i really think this would work as solution" sort of thing, and only for explaining of the problem sake.
Daniel
signature.asc
Description: OpenPGP digital signature
