Re: [gentoo-user] why multiple versions of java-config, automake, and autoconf?

[Enrico Weigelt]

* Bo Ørsted Andresen <bo.andresen@××××.dk> 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/
---------------------------------------------------------------------
-- 
gentoo-user@g.o mailing list