On Saturday 22 January 2005 17:52, Daniel Goller wrote:
> Stuart Herbert wrote:
> > 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.
>
> since we can change an eclass after it was used on a system chancxes are
> he can not reproduce the same result twice
If a reproducible system is what is wanted, the best way is to make ones own
backup of the portage tree at time of installation or last full upgrade.
> >>. 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.
>
> 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
I *mostly* agree with Stuart here in that a version bump on eclasses prior to
most any modification is just not worth it. There was a sentence along the
lines of "eclasses bring a little object orientation to ebuilds" in the old
ebuild howto, but it seems to have disappeared now...
Eclasses shouldn't need a version bump after every change. They just need an
unchanging well-defined interface. In other words, what ever variables and
functions are available can not change with regard to their inputs and
outputs. New functions and variables, on the other hand, should be no problem
at all.
> >>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
Let's take a look at the actual profiles.
# ln -sf /usr/portage/profiles/default-linux/x86/2004.0 /etc/make.profile
localhost ~ # emerge -ep system | grep dhcp | wc -l
0
Wasn't that only decided upon and implemented a few months ago?
> >>* 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
What purpose does versioning serve here? It allows old versions to continue
working because a dev made a mistake? That's more a bandaid than a fix. What
needs to be looked at is why such mistakes happen and fix that problem. Don't
get me wrong; mistakes will always happen. However, making eclasses versioned
won't actually lessen those mistakes.
> > 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?
>
> by merging the old ebuild
No guarantees that the ebuild hasn't changed either. Of course, that happens
very rarely in arch when compared to ~arch, but that's beside the point.
> >>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.
>
> 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
>
> > 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
As I said before, versioning does not fix the problem - it only tries to
sidestep it ( - but doesn't )
> >>* 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 could be defined what changes are allowed when to not compromise
> predictability
And for that you need a well defined interface for each eclass.
> > 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
It all about priorities. If we just went and did it, we'd get flamed. (Course,
procrastinating gets us flamed too ;) Having a release free of all known bugs
ready for 2005.0 seemed much more important at this stage.
> > 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.
This *should* be possible. Theoretically, any package should be able to be
used with any revision of an eclass released after that package. If not (and
yes it is not) there's no guarantees that people will be able to uninstall
their software - and yes this has caused problems already.
> 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
Versioning on every change means that we're going to have 10000 eclasses very
quickly. And no, the ones that aren't used by ebuilds in the tree can not be
removed. Any package that anybody has installed *must* have any utilized
eclasses available in the tree at this stage.
> > 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.
>
> 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
The question is "what are versioned eclasses meant to solve?"
> > 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
John's idea is good. Could even add a doc file to the mix to save the trouble
of having to maintain a set of eclass man pages, which could all serve as the
basis of whether a change will break documented behaviour or not.
> > 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.
Right.
> 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.
True that. I've also found that it's best to not bring solutions to the
opening of a discussion, even if you are sure that the solution fulfills all
the issues to be discussed. It sounds a little covert, but usually there is a
much better response.
Regards,
Jason Stubbs
--
gentoo-dev@gentoo.org mailing list
