On Sat, 2005-01-22 at 01:12 -0600, Daniel Goller wrote: > do i have to meddle in an eclass to be able to point out that one > version that is never constand used by many versions of ebuilds cant be > a good thing? im not sure what it is you are after here
Funny. Over on the games team, we have a single eclass that we use for
pretty much everything, and we haven't had problems like this. In fact,
it greatly simplifies our lives, being 4 developers that maintain
several hundred packages. The simple rule is that we don't commit
things that will break the tree. If we are forced to make changes that
could break the tree, then we change the affected packages and revision
bump it after doing extensive testing.
> can you already control that changes to an eclass do not affect a
> certain version of a package, if that package uses an eclass that has
> changed several times significantly in the version specific part, while
> the ebuild version has not? it is great we can do that (if people only
> used it), what the issue is here that two people can merge the same
> package version at different times and due to different versions of the
> eclass do not get the same results, during merging and or after
That is correct. There are many times when this is a good thing.
Allow me to give you an example. Let's say I had to edit the
games.eclass to change the user that our packages get installed as from
games to root, so that games will work with GRSEC's Trusted Path
Execution. Under your idea of how things should work, I would hav eto
bump the eclass version to make this change, then edit every single
ebuild under games-* and dev-games to inherit this new version of the
ebuild. So rather than making a simple one line change in a single
eclass, I have to edit several hundred ebuilds, revision bumping each of
them, which means the rsync infrastructure gets to get hammered 30
minutes later.
What you are proposing essentially breaks the functionality of eclasses
as a repository of shared code and turns them into an extension of
ebuilds.
Why not just remove eclasses altogether, then? Then you'll be sure that
the ebuild code will never change since all of the code would be in the
ebuild.
I've got a better idea! Let's remove FEATURES, too! Those can change
between portage versions and break predictability.
Now that I think about it. Portage's behavior has changed between
versions. Let's get rid of portage, too. We can just change all the
eclasses to shell scripts. It would accomplish the same thing in the
end, right?
> ie emerging foo-1.2-r1 in may should yield the same result as merging
> foo-1.2-r1 in july, while it doesnt
See above. It could very well be the desired effect, or do you not
understand progress and bug fixing?
> if you find this then means policy/how we do things should change not
> any existing technology, im listening
> i just happen to prefer a solution like 'cp foo-1.2.eclass
> foo-1.3.eclass && vim foo-1.3.eclass' a lot better to control than
> hoping that "they just do it right", maybe you have more faith in the
> people using eclasses than i do at this point? :)
I've got a better idea. How about a policy that says that if you break
the tree that you'll have disciplinary action taken against you? Oh
wait... We have one of those already.
What I find funny is that you *still* have not come up with a single
thing that versioned eclasses would really solve. You seem to think
that slapping a version on the end of an eclass is magically going to
make a developer's job easier and that everything will be perfect.
If you haven't noticed, people already do create new eclasses when they
make incompatible changes. They just name them something different.
Let's take some examples. First, we had kernel-mod, then kmod, and now
linux-mod. Each of them are incompatible with the other.
> > If you *do* have huge changes between package versions -- say, for
> > example, pcp4 to pcp5 -- there's nothing to stop you from doing a
> > pcp.eclass and a pcp-5.eclass. No need for any portageisms there.
>
> well like i said, id like that, just a little more fine grained, and no
> portageism is in my head, neither would i refuse "portageisms" if
> someone from portage team said, we could do that realy easy like...
> im not set on any one idea
Great! Then you have no problem with the games team giving you a big
one finger salute when you try to push this crap on us because we've got
enough sense to make sure we don't break our own eclasses, right?
> > So... What specific problems do you have with your eclasses that can't
> > be solved using either numbered or version-dependent code? If it's
> > something versionator can't do yet, maybe it'd be easier to add support
> > in there than doing huge changes to portage.
>
> again this is not that im limited to work on my eclasses, it is about
> how there should be more care about how we deal with eclasses, since one
> eclass can break many packages or even archs it wasnt tested on (of
> course that shouldnt happen, but it does, and we can talk about how to
> minimize damage once a pourly tested commit was made, and of course
> emphasize that such shouldnt happen)
Well, I seem to find it much easier to use cvs and o revert a single
eclass to a previous version from cvs than to go back to the previous
versioned eclass by filename, then edit every single ebuild that
inherited the new eclass, but maybe that is just me.
> > | * 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".
> >
> > This is why we test changes and do package-version-dependent code. The
> > situation's no worse than with ebuilds. If I make some huge changes to a
> > certain package and either remove all older versions or don't -r bump it
> > then the user is equally screwed. However, since I do testing and don't
> > apply eclass changes retroactively to older versions of packages, this
> > isn't an issue. The solution here is making sure developers really do
> > test things, not offloading proper QA into portage.
>
> i think we agree here that testing should be done, and proper QA might
> have avoided this thread from ever starting, i think versioned eclasses
> could lead to reduced man hours for thorough testing while dramatically
> increasing the gain in quality of our product
Prove it. You keep pointing out how you claim that it will reduce the
workload and improve quality, when I simply don't see it. In fact, I
see it doing nothing more than increasing the workload on each of us.
> a simple cp from one version of eclass to the next doesnt take long, we
> know the old version of the package foo, worked with the eclass version
> it inherits, and we no longer touch it, the new version eclass is then
> only inherited by future version of the package foo
> the bumped package foo that in herits the bumped eclass foo would end up
> in ~arch, where it can be thoroughly tested
> avoiding unnecessary compiles for our arch customers, while keeping a
> downgrade path for our ~arch customers open
How? By going back to the stable version? What about packages where
the stable and ~arch versions are already quite disparate? Will this
not only worsen the problem?
> even if it is from a ~arch to ~arch bump, we shouldnt inconvenience our
> ~arch customers any more than our arch customers when it comes to
> predictability of their systems
Not really. The ~arch is there for testing. It is expected that things
will move much more rapidly and possibly even introduce
incompatibilities, as that is the nature of testing. If someone wants a
stable platform, they should be running stable.
> > | * 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")
> >
> > Uhm... Checksums? We don't sign eclasses anyway just now, since portage
> > doesn't support it. For versioning, all eclasses should have a CVS
> > $Header$ line.
>
> like we said, it would be nice version x.y of eclass foo really hasnt
> changed, but that is a technicality to be solved down the road, for now,
> we would get it figured out which the least straining way is to really
> get predictability increased multifold
Well, for starters, we could take the developers that do this stuff
repeatedly without regard to what it does to the tree and take
disciplinary action against them.
You seem to imply that predictability is directly proportional to bugs
or mistakes, and it is not. They have absolutely no correlation.
Predictability gives you only one thing... predictability. It does
nothing to ensure the quality of the work.
> > | The sample eclass exploit of aholler should have made all people
> > | involved aware of those issues
> >
> > Just as easy to sign one eclass as it is to sign dozens of versions of
> > an eclass. Your argument here is completely bogus and suggests that
> > you're either trying to pass this off by sneaky underhand 'security!'
> > tactics or that you don't have a clue what you're talking about.
> >
> > Hint: not all of us run around like headless chickens whenever anyone
> > says the word 'security'. This might work for some people but those of
> > us who have experienced the Weeve know better.
> >
> > I'm not going to comment on all the problems I see in your proposed
> > implementation for now. Once the design is clarified I'll provide some
> > feedback, but for now I don't think it's worth considering given the
> > flakiness of the premises...
> >
>
> well let me know if you can comment on this, if not let me know what you
> want clarified so i can do so
Signing a single eclass or multiple eclasses has the exact same net
effect. Security plays no part in versioned eclasses, especially not as
you have presented them.
--
Chris Gianelloni
Release Engineering - Operations/QA Manager
Games - Developer
Gentoo Linux
signature.asc
Description: This is a digitally signed message part
