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

[Enrico Weigelt]

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

Hi,

> So, your suggesting the following would have been a better
> option in this case
>
> dev-lang/php4/php4-4.4.3.ebuild
> dev-lang/php4/php4-4.4.4.ebuild
> dev-lang/php5/php5-5.1.1.ebuild
> dev-lang/php5/php5-5.2.0.ebuild

Yes.

> virtual/php/php-5.ebuild -> dev-lang/php5/php5-5.2.0.ebuild
> virtual/php/php-4.ebuild -> dev-lang/php4/php4-4.4.4.ebuild
>
> ...  and ...  to have  .. slotted virtuals like jdk does =P

No. Not slotted !

Maybe some virtual for dependencies on an subset of php which 
works with both variants. Packages which are proven to run on
both variants can use this virtual, just to get the || dep 
out there.

> >What "folders" are you tallking about ?
>
> sys-devel/automake/automake-1.10.ebuild
> sys-devel/automake/automake-1.4_p6.ebuild
> sys-devel/automake/automake-1.5.ebuild
> sys-devel/automake/automake-1.6.3.ebuild
> sys-devel/automake/automake-1.7.9-r1.ebuild
> sys-devel/automake/automake-1.8.5-r3.ebuild
> sys-devel/automake/automake-1.9.6-r2.ebuild

Ah, you're talking about the per-package subdirs.
What's bad w/ having a few more of them ?

> as theres 1 slot here /per/ ebuild, it would cause a bit of
> namespace pollution were you to "upslot" them, ie:

Is this really such a problem ? 
Maybe we could add another step in the hierachy, 
ie. called "variant" or "evolution" or whatever ...

> instead of just one nice sys-devel/automake , you would need to have
>
> sys-devel/automake-1.10/automake-1.10-1.10.ebuild
> sys-devel/automake-1.4/automake-1.4-1.4_p6.ebuild
> sys-devel/automake-1.5/automake-1.5-1.5.ebuild
> sys-devel/automake-1.6/automake-1.6-1.6.3.ebuild
> sys-devel/automake-1.7/automake-1.7-1.7.9-r1.ebuild
> sys-devel/automake-1.8/automake-1.8-1.8.5-r3.ebuild
> sys-devel/automake-1.9/automake-1.9-1.9.6-r2.ebuild

Maybe it looks "nice" for you, but this looks like these
were (exchangable) versions. Obviously they're NOT.
These "evolution steps" are NOT compatible, neither upwards,
nor backwards. It's really a luck if some packages work with 
more than exactly one automake version.

The problem is that packages depending on those slotted ones
have to depend on specific version numbers. Maybe its not that
bad if the interface breaks only happen between major releases
(so you can say things like "=automake-1.7*"), but it gets
really tricky with breaks between minor versions. Some time 
ago I already had such situations w/ the autotools stuff.

> >> 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 reason for this, I believe, is that webapps regularly need to be
> hand-adjusted to suit the users needs, and needs hand tuning for each
> upgrade. Often this automated upgrade can break stuff ( can, but if
> you've not changed from default, it usually runs fine ), so I guess
> the reason is similar to the kernels, "less stuff breaking" i guess. (
> Although ATM, its unobvious how to switch between webapp slots :S  )

Yes, webapps are still an story of their own.
I don't see an better solution than the current webapp-config approach
for now. But I don't think slotting is really necessary here. 

> >Well, if the slot number would be an part of the package atom name,
> >it would be half as bad.
>
> I definately aggree, which would help many apps out in following
> problem slotting currently has : "It is not possible to DEPEND upon a
> package in a specific slot." [1]

Yep. If would make things much, much easier. It would IMHO also solve
your concerns about namespace pollution, etc. In fact different slots
then would be different (sub-)packages.

> For some things, such as things which require automake, & friends, it
> would permit them to use some sort of syntax such as
>
> %=sys-devel/automake-1.9
> %<=sys-devel/automake-1.9
> %>=sys-devel/automake-1.9

What shall that mean ? 
Use some specific range within some slot ? 

I could imagine some syntax like:

    sys-devel/automake/1_9
    
or
    sys-devel/automake+1_9
    
of
    sys-devel/automake%1_9

"1_9" then is the slot/branch/subpackage name. 
You probably reconize the missing "=". That'd be correct, since the
slot is not part of the version, but the package name.

> Why that syntax ?
>
> Well , we have a dilemour, if we were to change the way package atoms
> were named, it  would break /craploads/ of the stuff already available
> expecting the 'old way'

The new syntax should be an extension of the old one. An missing slot
name just means "choose best matchting slot".

> sys-devel/automake/automake-1.9.slot  <-- note the suffix.
>
> This file would contain none-other than a list of packages which
> comprise that slot.
> packages emerged without -1 would be injected into world as a 'user
> asked for this slot' ie: %sys-devel/automake-1.9
> thus preventing the erronious cleaning of slots,  and permitting
> packages to directly depend  on a given slot.

Ah, now I begin understand :)
If someone requests somethink like "%..." it means requesting an 
slot "..." instead of an package.

hmm. I see now fundamental difference to virtuals.
If you want to get it separated from virtuals, why not just putting
them into some "slots" herd/subdir ?

> In essence, this does what we did with virtuals. Virtuals I believe,
> either used to be defined in some global text file, or as a string
> inside each packages ebuild, but my memorys a bit rusty as to exactly
> how it used to work.
> This suggestion, is a de-ebuilding of slotting control somewhat.

_IMHO_, ebuilds are just ebuilds without own files, just to control 
dependencies. They're emerge'd as usual. At least seems so ;-O


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