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

[Kent Fredric]

On 6/9/07, Enrico Weigelt <weigelt@×××××.de> wrote:
> * Kent Fredric <kentfredric@×××××.com> wrote:
> > On 6/9/07, Enrico Weigelt <weigelt@×××××.de> wrote:
> > >
> > >What flexibility do I take away exactly ?
> > >And what exactly gets harder ?
> > >
> >
> > Automated building of dependant packages
>
> More precisely ?
> AFAICS it would be much easier w/o slots.
>
> I already mentioned "Briegel". Here I'm strictly doing as described.
> This works great. The only reason for using Gentoo is that it has
> much, much more manpower than me alone. For most common systems
> Gentoo is quite good, for embedded targets (where I've got relatively
> few packages) I'm using Briegel.
>
> > Gentoo has a collection of magic script that do make this nice for us.
>
> Which ones for example ? / What exactly do they do ?
> Would that magic be necessary with my approach ?
>
> > ie ( last I looked anyway ) java-config and autoconf were not binarys,
> > but scripts which pointed to the correct binary given the right
> > environment variables.
> >
> > This makes the building of other packages that were invented upstream
> > without predicting changes in autoconf easier to maintain, instead of
> > having to send out a new patch every time upstream releases a
> > non-compatible-with-new-autoconfs version /just/ to make it work, we
> > just set WANT_AUTOCONF=1.4 in the environment and the appropriate
> > autoconf gets run, which seeems a fairly reasonable thing to do. (
> > otherwise the concept we have today known as a version bump would be a
> > whole deal harder more often)
>
> Yeah. Wrapper scripts. I also have such things @ Briegel.
> Please explain why this is an reasonable argument in the question
> whether or whether not to do slotting ?
>
> > I remeber the days of Java1.4 -> Java1.5 migration headaches before
> > they slotted it and created java-confing system to get around it,
>
> Would it make a difference if sun-java-1.5 would have got it's own
> package name (distinct from -1.4) ?
>
> AFAIK -1.4 and -1.5 are really incompatible, almost as much as
> gtk-1.x vs. gtk-2.x. So why not treating them as different packages ?
>
> > As for gtk2-0.1 vs gtk-2.0.1, the latter is clearly a more logical
> > version number.
>
> Why not gtk2-2.0.1 ?
>
> > if it was called gtk2 instead of gtk-2, it would need a separate
> > folder, and a completely different set of configs,
>
> Yes, of course - it's an different package.
>
> > it was bad enough when php4 & php5 were different applications.
>
> Why ?
> php4 and php5 are very incompatible, almost as much as it had been
> with php3. This already had been clear when php5 was at alpha.
> I never ever expected them to be the same package.
>
> Of course evrything would be much clearer if there was an big
> consensous on naming the scripts with *.php4 and *.php3 as it
> had been done in history w/ php3. But this really has nothing to
> do with slotting vs. separate packages.
>
>

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 currently develop in 5 and then serve on 4, and even that has
minimal errors in translation, so its not all /that/ bad. Same with
java 1.4<-> 1.5, in most cases, the code the 'user' would be running
needs minimal fixes, its just the bigger packages that cause the
problems.  ( I cant say if i know this is  the case with GTK tho ..
never been much of my feild of expertiese )

So we have a scenario where we have a mingling of styles for diferent
user targets,
we have slotting to keep the builds happy with unique versions, but we
still have a migration path for users.

Maybe to you that seems illogical, but to me, its handy and convenient.

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? )

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

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.

Maybe slots are over abused in some cases, but there are IMO many uses
for them which I'm thankful for, and in some cases where I wish
packages had slotting on them. Mysql for instance was going slotted,
and i wanted to be able to have 2 concurrent mysqls with one with
debug flags and the other not, so when things went nasty i could click
in the debugged one to find the problem, but not have to run the
debugged one 24/7 and fill my hard drive @ 5G/min,  but unfortunately,
they didn't  have developers who could be bothered so it got dropped.

-- 
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil kdrtf@×××.com"[(2*x)..(2*x+1)]}'
-- 
gentoo-user@g.o mailing list