On Sat, 2005-01-22 at 10:32 -0600, Daniel Goller wrote: > > No. If I *want* to make a change to an eclass that affects all the > > packages that inherits it, under your proposal, I would have to make a > > new version of the eclass, then edit every single ebuild that inherits > > that eclass. The whole *point* of an eclass is to have shared code. To > > only have to edit one place to make what would otherwise be very tedious > > changes. Your proposal breaks the functionality of eclasses. > > under my proposal you make a new version of the eclass, but no you dont > go edit every ebuild that uses that eclass, or in a more precise point, > yes you edit EVERY ebuild that uses that NEW eclass, that ONE ebuild > that will start to use the new eclass, i wouldnt say the workload isnt > affected by it much at all if my proposal would require you to edit 20 > ebuilds just cause a new version of a package requires you to actually > change the eclass, not the ebuild
First of all, have a little courtesy and cut the quotes from previous emails down to what you're responding to. It makes a response much easier to read and is good for people on slower links. Anyway, you completely skirted my question by answering something completely different. We *rely* on the current eclass implementation to make wide-spread changes. We don't *want* to have to edit every single ebuild to make simple changes. That is the whole purpose of sharing code between ebuilds. Does this just not make sense to you? > > This is a case where this works, simply because all kernels are similar, > > especially of the same major and minor version. > > > > Now look at games.eclass, which serves several hundred completely > > independent packages. Where would versioning help me? > > > > How about eutils.eclass? Just because I want to use the new > > domenu/doicon stuff I have to bump every single ebuild that I want to > > use it? Does that not defeat the purpose if "inherit eutils" was > > already in the ebuild? If I wanted to have to inherit something > > different every time a change was made, I would just make a new eclass > > entirely. > > > > here is where idea about links comes back into play, then a simpe change > of a link could inherit things like eutils.eclass and games.eclass, > because we do have versioned eclasses in tree this is possible > there could be a split solution, system package require absolute > inheritance, while packages can use either absolute inheritance or > indirect via symlinks I'm sorry, but what the hell would that help other than to add a bunch of complex crap to the tree that would better be served by just having them all inherit the single eclass? Have you ever heard of a header file in C? Consider an eclass to be the same thing. Code that is shared by all of the ebuilds. They are supposed to act the same, not act differently for the same functions. A user should be able to look at games_make_wrapper and know how it will work, not having to worry about how it will work on *this version* of the eclass. You are proposing to take a simple system and make it overly complex and confoluted for the purpose of what, exactly? To have some version numbers on something that shouldn't be versioned to begin with? Like I said, I have no problem with *you* using versioned eclasses, but don't be surprised when I don't, because I have sense enough to not break backwards compatibility in my eclasses. > this way a system can still be locked in, you can lock the version of > ebuild you want, and lock the appropriate eclass, which people will > scream "mix and match, mix and match!" > one solution avoids mix and match but makes people see only one finger > saluts coming the way of those who proposed this, the other way they > would be seeing less work (not saying either one actually creates all > the extra work you fear), but others would fear mix and match What are you arguing here? So long as the interface is the same, what difference does it make if the underlying function completely gets rewritten? I really hope you stop to think about what you're posting before you respond to this, because some of your retorts are becoming nearly unreadable. Your use of euphemisms and vague references really makes you look like you're completely talking out of your ass. If you want to make a retort to something I say, say it. Don't beat around the bush. We aren't in middle school here. As for extra work, I've already explained where this would cause excessive amounts of work for not only myself, but for architecture teams, and you response is essentially "No, it won't." Huh? Care to explain how it will not cause work? By your own admission, if I make *any* changes to an eclass, you expect me to version bump it. If I *want* it to modify every ebuild that inherits it, I would have to bump *every* ebuild's version and change the inheritance rather than edit the one or two lines in an eclass, as things are now, and be done. How does this not make sense? Are you simply avoiding answering this question because you have no answer to how you would prevent this? > i acknowledge you fear much extra work, and from your points i > understand you edit games.eclass all the time and will make sure to have > a solution that will not cause a "Berger-style" angry two finger > incident (you watch Sex and the City and know what i mean, right? ;) Great, then you don't mind when I tell you where to shove this proposal as I continue working with my one eclass and don't bother versioning it. I don't get the Sex and the City reference, as I don't watch it. -- Chris Gianelloni Release Engineering - Operations/QA Manager Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
