On Saturday 22 January 2005 08:12, Daniel Goller wrote:
ie emerging foo-1.2-r1 in may should yield the same result as merging foo-1.2-r1 in july, while it doesnt
Even without eclasses this is more than likely not true. The results of merging (compiling) a package are possibly dependent on the whole system. If you want to guarantee that the results are the same, use binaries. Even dependencies can break when a newer version of a library is released that an application can not handle. That's why we have bugzilla and maintainers, things change, and need to be constantly kept up to date.
Paul
if the whole system is more predictable then merging of an ebuild version in may and in july would be more predictable, if the binaries change between may and july, the same problematic is still there
if we ca not achieve 100% predictability, we should still try to increase our predictability to the highest reachable level
in turn fixing bugs should turn out simpler in the end too, as a quick glance in foo-1.3.ebuild would see it now inherits foo-1.2.eclass where all previous versions inherited foo-1.1.eclass and worked fine, and while devs do not depend on versioned eclass to diff, it keeps the users systems going w/o being stuck with "new version doesnt work and now old one wont merge anymore"
and the dev can do a cvs diff to find what changed between the two versions, as the ebuild would already tell him whch version of the eclass is broken, saving valuable time figuring out which eclass version in cvs it might be that introduced the bug
if a newer library is released the user sees that library in ~arch first, and can decide to wait till it hits arch, or decide to test it prior to that, if it works or not, he still has the old version available, ready to be remerged (he could have a testbed on which he tests the library and a production machine benefittin from it, he would test it to help find bugs and thus see it in arch for his production machine sooner, now he did all the testing on the testbed, and the new lib hits arch, what he tested he can not reproduce, cause a even newer version of the library caused a required eclass to change, now his production system has changed from what he expected and his customers charge him for the outages they encountered, or maybe his boss is mad cause a important client didnt get to see a demo of a new 3d engine they were interested in testing)
my point is versions of libs allow reverting to a working version, those who find a problem in the new version of the lib can report it and the lib can be fixed before the majority of users is affected, especially no arch users would be affected, and additionaly a smaller number of ~arch users, than would be the case w/o versions
versioned eclasses would allow more possible/precise reverting or "locking of profiles" as is possible today with a minimal effort required on the gentoo/dev side
Thanks,
Daniel
signature.asc
Description: OpenPGP digital signature
