maillog: 22/01/2005-01:12:10(-0600): Daniel Goller types > Ciaran McCreesh wrote: > >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
I can give a real-life example: I emerged gcc recently (yesterday) and it was completely broken. After trying out different versions, I found that the problem was caused by a script from the Globus Toolkit. Point is, that script is setting some environment variables to make it possible to use the GT. Among the LD_LIBRARY_PATH, PATH, etc... it was also setting a LIBPATH variable. So, a new version of the toolchain eclass was using that LIBPATH variable and was breaking up. -- -* Georgi Georgiev -* Bender: "Argh. The laws of science be a -* *- [EMAIL PROTECTED] *- harsh mistress." *- -* +81(90)6266-1163 -* -*
pgpIfcOT5wT1F.pgp
Description: PGP signature
