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

[Enrico Weigelt <weigelt@metux.de>]

* Kent Fredric <kentfredric@gmail.com> wrote:

> Ah, but you see, in half the cases there is not a /complete/
> incompatibility.  PHP4<->5 migration is not an entirely big switch,
> the biggest problem IIRC in the 4->5 change is the way it handles
> classes, and a lot of code 'simply works' on both.

I had to do a lot at that front. Believe me, they're NOT compatible. 
Just nearly compatible. So different.
For those packages where it really doesnt matter, we simply could 
use an virtual.

Sama for java.

<snip>

> In the case of autoconf, im personally glad it all hides under one
> non-linear space-time-continumum on my harddrive ;) . The thought of
> them all being in seperate ebuild names would drive me nutty ( folder
> with 10 different package names for the same thing = wtf? )

What "folders" are you tallking about ? 

<snip>

> The argument of 'cleaning' was a problem for a little while, but im
> glad the kernel uses slotting, for the reason I dont want to have a
> seperate ebuild for different kernels, i dont want old kernel sources
> to be taken away when the new one turns up, and when i want to get rid
> of old kernels, i want to be able to do a nice and simple emerge -C
> <=some-version  to get rid  of them when im done with them. 

Okay, that's good point where slots are really useful.
But I'm sure there could be other good solutions.

> The same occurs in many of the web-applications, where multiple versions 
> are handy, but multiple ebuild names would cause headaches.

hmm, they're an special things, since we can have many instances 
of the same application here. but I never had the need to have 
multiple versions of one webapp (source) installed.

> the only way to get around all these nasties would be to have a 3 part
> package name imo, such as
> dev-libs/gtk/2/2.0.1.ebuild
> dev-libs/gtk/1/1.0.1.ebuild
> for instance , and when you look at it like that, it is in essence
> identical to 'slots', except a 'slot' is governed by a string in the
> actual file, instead of  a string in the filename.

Well, if the slot number would be an part of the package atom name, 
it would be half as bad.


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@gentoo.org mailing list