* Bo Ørsted Andresen <[EMAIL PROTECTED]> wrote: Hi,
> Wtf. Newer versions are newer versions. No matter if they are > fully backwards compatible or not. I really don't aggree your really loose view of "versions". That's like seeing ISDN as an newer version of POTS. Well, if you're convinced about that, feel free to pull in an POTS phone on an UK0 line and see what happens ;-P (at your own risk!) > The point is from the package manager point of view it would be > trivial *because* the developers would have to do more of the > work manually. Which "manual" work do you exactly mean, ie. if you simply treat gtk-1.x vs. -2.x as separate packages ? > I.e. the work of creating new packages, removing old ones and > creating/updating virtuals where they currently just do version > bumps and remove old ebuilds. Is this really that much more than maintaining *version* dependencies on every single package which depends on slot'ed packages ? For example gtk: it would add only one more package, but make all version deps onto it, in every gtk using package, obsolete. > I also *really* don't see how adding a dep on =automake-1.4* or > automake:1.4 is harder or more complex than automake1.4 (which > currently would be an invalid package name anyway). Well, what do you do if, ie. -1.9.3 would be incompatible to -1.9.2 ? I already had such cases with autotools stuff some time ago. Ah, and the whole extra complexity (in portage and ebuilds as well as for the admin) in having to cope with multiple versions means nothing to you ? > The reason why cleaning cannot be done properly for packages in > system or world is that the packages files that define the system > set in the profiles and the world file don't support specifying slots. Right. If at least slot would be (optional) parts package names, this would be much easier. > [SNIP] > > Same with autoconf. The numbering is not that easy here, since > > major breaks sometimes happen with minor version changes. So > > we just have to look a bit more cafully. But still much simpler > > as adjusting all these versioned dependencies which are necessary > > with slotting. > [SNIP] > > Indeed the real problem is that the current EAPI supports neither slot deps > nor ranged deps (with the exception of the not too powerful =foo* syntax). So please tell me how you could handle such an case. > > The Idea of this "linear" version space is that we can compare each > > version with another one very easy. Additionally use the axiom that > > higher versions are always successors of lower ones and backwards > > compatible. In this situation the whole package management story > > is really easy. Things like slots are not necessary. If we also take > > in binary compatibility, revdev-rebuild is also not needed. Evrything > > is strictly defined in the dependency graph. > > Wow. You're actually suggesting making a new package not only on API > breakage but even on ABI breakage (otherwise revdep-rebuild would > still be needed)? At least on API break. If we also do it on ABI, we would have more breaks, but compatibility would be ensured just by the dependencies. Most of my jobs are building and maintaining firmware for embedded systems. Here MUST ensure binary compatibility on upgrades. There is nothing like revdep-rebuild, even no compiler on the target system. So you maybe can understand my constraints why I'm often very quick in declaring things "broken" :) > > What if now comes an 1.4.99 which is totally incompatible with the > > other 1.4.* ? What do you do now ? > > Add a 1.4.99 slot? Just like you'd create a new package for it and > add that to the virtual? Yes, of course. But what's with the packages depending on it ? See: > > Drop that 1.4.99 ? > > Give it another version, ie. some 1.5.* ? > > Touch all depending patches to exclude 1.4.99 ? > > Huh? Your answer's still missing. How to you handle that ? > > What flexibility do I take away exactly ? > > And what exactly gets harder ? > > The ability to have more than one version of the same package > installed at the same time. Would be simply not necessary if these incompatible packages were treaded as separate ones. ;-P In fact, slotting (IMHO) does not allow real MVCC. This would require *each* version its own slot and every version installed somewhere else. But MVCC is an topic for its own ;O > What is now a simple version bump (that happens to use a new slot) > or cleaning of obsolete versions becomes packages additions and > removals plus updates to virtuals. Ok, then we maybe have to touch one or two more files (for the virtual). But the good side is that we don't necessarily do it in one step. And we're not limited to one virtual. For example php: we've got an virtual/php-v4, which represents the v4 style runtime system (or at least an subset of it). Certain versions of php5 match in here, so they can be added to the virtual. But we cannot be sure that all future versions will still fit in here. We need to decide it for each single version. Without such an virtual, we often have to touch every php depending package one by one. But with that virtual representing our common interface/environment, we've got one central point for that. Okay, this isn't really about slots vs. no slots, but shows that slots are not necessary. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ --------------------------------------------------------------------- -- [EMAIL PROTECTED] mailing list
