On Thu, 20 Jan 2005 22:25:55 -0600 Daniel Goller <[EMAIL PROTECTED]> wrote: | Since the last few discussions ended in a flamewar, we'll try to | present our arguments with some comments and some ideas on | implementation. Please don't go "Booo hiss eeeevil!" now. That gets | boring after a time ;-)
Ok. It'd probably help if you two let everyone know which eclasses you work with on a regular basis so that we can figure out how this relates... The problems you describe don't seem relevant to any of the eclasses I work with, but maybe the ones you use are different.
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
| * We want a reproducable system. 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. 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.
It's already entirely possible to do eclass changes only for certain versions of a package. Several eclasses do this already. Remember that eclasses aren't supposed to be used for version-specific things, so the only time the certain versions thing applies is when there're relatively small changes between versions, such that it's not worth not using an eclass function.
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
ie emerging foo-1.2-r1 in may should yield the same result as merging foo-1.2-r1 in july, while it doesnt
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? :)
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
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)
| * 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
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
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
| * 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
| 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
Daniel
signature.asc
Description: OpenPGP digital signature
