I feel like neither you nor Patrick are listening to anything any of us are saying on this subject, but I'll give it one last shot.
On Saturday 22 January 2005 08:52, Daniel Goller wrote: > since we can change an eclass after it was used on a system chancxes are > he can not reproduce the same result twice If we wanted the user to reproduce the same result, we wouldn't be updating the eclass in the first place. > > cvs diff is your friend here. The sort of versioned eclasses you are > > asking for add no value here to devs. > > 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 > 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 a) Our users are not customers. Please do *not* talk about them that way. They're much more important than that ;-) b) Your scenario is flawed. Most users do not attempt to install specific versions of a package. So a bumped ebuild inheriting a broken versioned eclass means that, for most users, the package is just as broken as it would be today. > 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 As long as the old ebuild is in the current tree, your statement is correct. If an eclass change breaks any ebuild in the tree, then either the ebuild or the eclass needs fixing. But I don't agree that we should be making it possible for users to take eclasses from the current tree, and use them with ebuilds that we have removed from the tree. And that is what it sounds like you think should be possible. > 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 > > 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 We don't need your proposal of versioned eclasses to "do control what we do". > > 3) They can restore files from their regular backups. > > see 2) What sort of an answer is that? > > Who goes around telling users to "read changelog, grab file from viewcvs, > > copy to /usr/portage/eclasses, hope it works"? I want names please. > > 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? You didn't answer my question. Who goes around telling users to grab files from viewcvs? Reverting an eclass is no guarantee that the package will be installed correctly. Eclasses are normally changed to fix bugs after all. > > We change ebuilds sometimes without version bumps. It's expressly > > encouraged under certain circumstances. Are you saying that this > > practice should also change? > > 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 No no NO! There are very good reasons behind the current Gentoo policy on ebuild rev bumping. You think it would be a good idea to put those reasons to one side? Or have you forgotten why they are there? > > How many users run without the 'strict' FEATURE enabled? Our install > > stages don't even ship with this switched on! > > 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? Personally, I think that we should ship with 'strict' enabled on all arches which support it. There should never be a bad digest. > We will involve them once the actual idea about how to do the versioning > is brought along further So you'll ask the Portage team what they're doing about eclass versioning at a later date?!? I doubt they'll be as polite to you as I'm being. > , 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 Go read the Portage source code. I'm sure once you understand how eclasses are currently implemented, you'll then be in a position to reconsider that statement. > , 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 As several of us keep telling you: digest / signing of eclasses has nothing to do with versioned eclasses. They are two separate requirements. > > There's no reason to suggest a new version number scheme just for > > eclasses. > > you forget something here Sorry, no I don't. I think adding a second versioning scheme to Portage just to support eclasses is a ridiculous idea. There's no reason why versioned eclasses couldn't support the same version rules as ebuilds do. And it would mean that you'd get ATOM support for free. What you're suggesting seems to be bad engineering. It is in no-one's interest for Portage to contain bad engineering. > at ths point i lean more towards the suggested bumped eclasses through > copying them to new versions, similar to bumps on ebuilds Cut n paste programming is very distasteful. It's unecessary, it's poor engineering practice, and I personally would support seeing all those who teach this practice being disbared for life from teaching software engineering in any shape or form. > 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 and > 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 lots more like it. Ah. This thread, like the last one, hasn't come across as you seeking answers to a problem. They've come across as "we want to make this change to Gentoo". > 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 Yes, they do. Preventing them from doing so via software is not the answer. We should expect a higher standard from our devs. We should expect them to understand why certain things need doing in a certain way. If they're not capable of understanding the why, then they shouldn't be devs. And out in the adult world, sometimes the rules have to be broken. That's why an educated dev is more use to us than a dev who is also told "you have to do this every time, and the software won't let you do it any other way just to make sure". > no we want: > 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 Thank you for clarifying that. Can already be achieved. See the nxserver eclasses as an example of this already happening today. > 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 I'd hazard that it was misunderstood because your email starts with a solution, and not with the problem that you are trying to solve. It's not your wording that seems to be the problem ... it seems to be that you're not used to presenting problems for peer review. > 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 Where are these problems? You've only posted one bug to support your argument. 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
