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

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

[Denis]

Hi all...

This is the output of "emerge --info" for the Gentoo box that I'm
still configuring - fresh install.  I configured and compiled a
working version of the kernel, configured CFLAGS and USE flags, etc.
I also ran "emerge -eD system" and "emerge -eD world" and updated /etc
configs accordingly.

Now...  Why are there multiple versions of java-config, autoconf, and
automake shown on my system?  There could be other multi-version
packages...  Is this normal for portage that is configured to
autoclean?  If so, I find it rather interesting that packages would
depend on so many different versions of automake, for instance!

Portage 2.1.2.7 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.5-r3,
2.6.20-gentoo-r8 i686)
=================================================================
System uname: 2.6.20-gentoo-r8 i686 Intel(R) Core(TM)2 CPU
6600  @ 2.40GHz
Gentoo Base System release 1.12.9
Timestamp of tree: Wed, 30 May 2007 16:50:01 +0000
dev-java/java-config: 1.3.7, 2.0.32
dev-lang/python:     2.4.4-r4
dev-python/pycrypto: 2.0.1-r5
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.6.3, 1.7.9-r1, 1.9.6-r2, 1.10
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=prescott -pipe"
CHOST="i686-pc-linux-gnu"
-- 
gentoo-user@gentoo.org mailing list

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

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

On Wednesday 30 May 2007 21:23:00 Denis wrote:
> Why are there multiple versions of java-config, autoconf, and
> automake shown on my system?

They are incompatible, slotted, and each slot is individually required (or was 
at some time).

> There could be other multi-version 
> packages...  Is this normal for portage that is configured to
> autoclean?

Yes.  Autoclean doesn't uninstall versions in a different slot.  I'm not sure 
about depclean.

> If so, I find it rather interesting that packages would 
> depend on so many different versions of automake, for instance!

HA.  autohell is that way because there's little backward or forward 
compatibility.  (Well, that and m4.)

-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Ric de France]

Hi,

On 31/05/07, Boyd Stephen Smith Jr. <bss03@volumehost.net> wrote:
> > There could be other multi-version
> > packages...  Is this normal for portage that is configured to
> > autoclean?
>
> Yes.  Autoclean doesn't uninstall versions in a different slot.  I'm not sure
> about depclean.

I think what is more useful is --prune (I'm guessing as I'm not in
front of a Gentoo box at the moment). I usually try:

# emerge -Pp

to see all the possible "pruning" that can be done. Then individually
prune packages using:

# emerge -P <package name>

I'm sure there's a better way to do things. Also be sure to follow up
a prune with a "deep world" emerge, ie.:

# emerge -DNuva world

It'll make sure if you prune something like automake that isn't back /
forth - compatible will be restored to your system.

HTH,

....Ric
-- 
Ric de France
Ph: +61412945554 (international) or 0412945554 (Australia)
 ==> Do you, uh... Gentoo? Gentoooo-hooo!! <==
==> http://www.gentoo.org/main/en/about.xml <==
-- 
gentoo-user@gentoo.org mailing list

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

[Denis]

On 5/30/07, Ric de France <rdefrance@gmail.com> wrote:

> I think what is more useful is --prune (I'm guessing as I'm not in
> front of a Gentoo box at the moment). I usually try:
>
> # emerge -Pp

Here's the output:
________________________________________
myhost etc # emerge -Pp

>>> These are the packages that would be unmerged:

 dev-java/java-config
    selected: 2.0.32
   protected: 1.3.7
     omitted: none

 sys-devel/automake
    selected: 1.10 1.6.3 1.7.9-r1
   protected: 1.9.6-r2
     omitted: none

 sys-devel/autoconf
    selected: 2.61
   protected: 2.13
     omitted: none

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.
________________________________________

But doesn't --prune just remove all but the most recent installation
of a given package?

While on the subject, I ran a pretend on revdep-rebuild, and it's
complaining about some broken libraries in GCC...
________________________________________
langevin etc # revdep-rebuild -p -v
Configuring search environment for revdep-rebuild

Environment mismatch from previous run, deleting temporary files...

Checking reverse dependencies...

Packages containing binaries and libraries broken by a package update
will be emerged.

Collecting system binaries and libraries... done.
  (/root/.revdep-rebuild.1_files)

Collecting complete LD_LIBRARY_PATH... done.
  (/root/.revdep-rebuild.2_ldpath)

Checking dynamic linking consistency...
  broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires
/usr/lib/lib-gnu-java-awt-peer-gtk.la)
  broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires
/usr/lib/libgcj.la)
 done.
  (/root/.revdep-rebuild.3_rebuild)

Assigning files to ebuilds... done.
  (/root/.revdep-rebuild.4_ebuilds)

Evaluating package order... done.
  (/root/.revdep-rebuild.5_order)

All prepared. Starting rebuild...
emerge --oneshot -p -v =sys-devel/gcc-4.1.2

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-devel/gcc-4.1.2  USE="fortran gcj gtk mudflap nls
(-altivec) -bootstrap -build -d -doc (-hardened) (-ip28) (-ip32r10k)
(-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc
-test -vanilla" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB
Now you can remove -p (or --pretend) from arguments and re-run revdep-rebuild.
________________________________________

I'm a little uneasy doing a --oneshot emerge of GCC when I just
recompiled my system twice...  I'm not sure how that will affect my
GCC upgrades in the future.  I only upgraded a minor version of GCC,
too.  Any thoughts?
-- 
gentoo-user@gentoo.org mailing list

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

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

On Thursday 31 May 2007 05:53:08 Denis wrote:
> On 5/30/07, Ric de France <rdefrance@gmail.com> wrote:
> > I think what is more useful is --prune (I'm guessing as I'm not in
> > front of a Gentoo box at the moment). I usually try:

--prune makes no checks of what's still required.

[SNIP]
> But doesn't --prune just remove all but the most recent installation
> of a given package?

Yes.

> While on the subject, I ran a pretend on revdep-rebuild, and it's
> complaining about some broken libraries in GCC...
[SNIP]
>   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires
> /usr/lib/lib-gnu-java-awt-peer-gtk.la)
>   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires
> /usr/lib/libgcj.la)

https://bugs.gentoo.org/show_bug.cgi?id=125728#c29

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Denis]

> > While on the subject, I ran a pretend on revdep-rebuild, and it's
> > complaining about some broken libraries in GCC...
> [SNIP]
> >   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires
> > /usr/lib/lib-gnu-java-awt-peer-gtk.la)
> >   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires
> > /usr/lib/libgcj.la)
>
> https://bugs.gentoo.org/show_bug.cgi?id=125728#c29

Oh fun!  found me a bug...  which is still "open" for over a year...
It's funny how my other Gentoo box doesnt have any broken GCC
libraries (although also upgraded to GCC 4.1.2) but instead has a
broken GIMP library that needs libexif.so.10.

So...  edit the *.la files or create symlinks? ;-)
-- 
gentoo-user@gentoo.org mailing list

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

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

On Thursday 31 May 2007 06:25:58 Denis wrote:
> > > While on the subject, I ran a pretend on revdep-rebuild, and it's
> > > complaining about some broken libraries in GCC...
> >
> > [SNIP]
> >
> > >   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires
> > > /usr/lib/lib-gnu-java-awt-peer-gtk.la)
> > >   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires
> > > /usr/lib/libgcj.la)
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=125728#c29
>
> Oh fun!  found me a bug...  which is still "open" for over a year...
> It's funny how my other Gentoo box doesnt have any broken GCC
> libraries (although also upgraded to GCC 4.1.2) but instead has a
> broken GIMP library that needs libexif.so.10.

Those two .la files only exist when the gcj use flag is enabled for gcc.

> So...  edit the *.la files or create symlinks? ;-)

Yes.

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Denis]

> >   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgcjawt.la (requires
> > /usr/lib/lib-gnu-java-awt-peer-gtk.la)
> >   broken /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/libgij.la (requires
> > /usr/lib/libgcj.la)
>
> https://bugs.gentoo.org/show_bug.cgi?id=125728#c29
>
> --
> Bo Andresen

Thanks, Bo -- editing the .la files fixes that problem.

Now that the dependencies are fixed, I don't need to rebuild anything,
do I?  I guess if this was a problem with any of the ebuilds I merged
onto the system before I fixed the dependencies, emerge would have
resulted in an error?
-- 
gentoo-user@gentoo.org mailing list

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

[Ric de France]

HI...

On 31/05/07, Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:
> --prune makes no checks of what's still required.
>
> [SNIP]
> > But doesn't --prune just remove all but the most recent installation
> > of a given package?
>
> Yes.

I knew there was a reason I followed a "--prune" up with a "-DNuva
world" as well as a "revdep-rebuild".

...Ric
-- 
Ric de France
Ph: +61412945554 (international) or 0412945554 (Australia)
 ==> Do you, uh... Gentoo? Gentoooo-hooo!! <==
==> http://www.gentoo.org/main/en/about.xml <==
--
gentoo-user@gentoo.org mailing list

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

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 519 bytes --]

On Thursday 31 May 2007 04:43:07 Boyd Stephen Smith Jr. wrote:
> > There could be other multi-version
> > packages...  Is this normal for portage that is configured to
> > autoclean?
>
> Yes.  Autoclean doesn't uninstall versions in a different slot.  I'm not
> sure about depclean.

With the latest versions of portage --depclean does clean unneeded slots for 
packages not in system or world. Since system and world doesn't support 
specifying slots it can't do it for those though.

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

On Thursday 07 June 2007 01:44:39 Enrico Weigelt wrote:
> > Now...  Why are there multiple versions of java-config,
> > autoconf, and automake shown on my system?
>
> These are packages totally incompatible and so different
> packages under the same name. They're sometimes necessary,
> since certain projects still require very old version,
> even if upgrade wouldn't be such a problem and has already
> been done by contributors (ie. mozilla).

Well, they still are different versions under the same packages from the same 
projects.

> Gentoo has an strange magic for handling that, called "Slots".
> They deeply break the linear version space. This makes handling
> very tricky and requires much additional complexity. Some of
> the other replies should make clear some prolems ...

I have no idea what breaking 'the linear version space' means. And I don't see 
how having automake in 7 different packages instead of seven slots under the 
same package makes it any less complex.

How is having a depend on =sys-devel/automake-1.4* or sys-devel/automake:1.4 
any more complex than a depend on a separate packages named 
sys-devel/automake-1.4 ? There are actuallly packages in the tree that don't 
care which version of automake is in use (at least according to there 
ebuilds). Now they just depend on sys-devel/automake. With your brilliant 
solution they would have to depend on || ( sys-devel/automake-1.4 
sys-devel/automake-1.5 ... ).

> No idea, why the responsible Gentoo-devs didn't just give
> those incompatible packages different names, especially on
> their own packages. AFAIK, java-config is made by Gentoo.
> It would be trivial, just to call the 2.x version something
> like java-config-2 ... perhaps too simple for them ?

It still doesn't change the problem that if they have different files with the 
same name they need to install it in different places. That problem is just 
the same whether in slots or separate packages.

[SNIP]
> As someone else already that: one of the problems with slots.
> They don't work well on cleanup. I wonder if anybody ever thought
> about that when slots were introduced.

--depclean does actually remove unneeded slots now for packages not in system 
or world.

By removing slotting you take away flexibility and make things in a source 
distribution harder. Not easier. Yes, it sucks that our current EAPI doesn't 
support that flexibility properly (by allowing slot deps) and that our 
current package manager doesn't support the flexibility that use deps would 
provide (hence dying in pkg_setup when a use flag was required). But the long 
term solution is not to remove the flexibility that these concepts provide 
but rather to support it properly in the package manager and EAPI.

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Enrico Weigelt]

* Bo Ørsted Andresen <bo.andresen@zlin.dk> wrote:

Hi,

> > These are packages totally incompatible and so different
> > packages under the same name. They're sometimes necessary,
> > since certain projects still require very old version,
> > even if upgrade wouldn't be such a problem and has already
> > been done by contributors (ie. mozilla).
> 
> Well, they still are different versions under the same packages 
> from the same projects.

Evolutionarily yes, technically no ;-P
They're in fact very diffrent, but provide an very similar
(almost the same) functionality.

The problem is: upstream claims that newer evolutions steps 
were newer versions, Gentoo takes it as it is and runs into 
trouble, the attempt to fix this is slotting. 

If we simply would consider them as different packages,
the whole story would be trivial. We just have to decide at 
which point a split has to be done. The whole complexity of
slotting and the still unsolved problems (ie. cleaning up)
could be dropped and dependency handling would be easy.

For example gtk:

First there was gtk-1.x. Later came gtk-2.x. They never were
compatible (except maybe early alpha state ;-)). They always
have been different packages, very similar, but different.

So if gtk-2.x would simply be called gtk2, the whole idea of
slotting wouldn't be necessary here. There are packages depending
on gtk and others depending on gtk2. Trivial.

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.

Maybe it would be different if the slot number would be essential
part of the package atom. But I'm not sure if it's really necessary
to have such an additional complexity if there is an clear scheme
for putting those "evolution levels" into the package name.

Gentoo always tries to stay as near as possible to the upstream.
Thats okay, if we're talking about patches. But taking those crappy
versionings from the upstream IMHO produces unnecessary trouble

> > Gentoo has an strange magic for handling that, called "Slots".
> > They deeply break the linear version space. This makes handling
> > very tricky and requires much additional complexity. Some of
> > the other replies should make clear some prolems ...
> 
> I have no idea what breaking 'the linear version space' means. 

Let's try some little (some bit mathematic) definition:
 
Version numbers are living within an scalar 1-dimensional space, 
ie. like rational numbers, but with holes. (ups, it's not really 
linear if we have holes ;-o). But all numbers are comparable with 
<,>,= operations. We normally represent them as n-vectors, ie. in 
form of 1.2.3.4 but in fact the right side dimensions are intervals
in the left side ones. Assuming the digits may take 0..9, we could 
define the scalar value of A.B.C.D as A*1000+B*100+C*10+D ...

(My Briegel buildsystem, which is a little bit like portage, but for 
embedded/crosscompiling, uses this model as well as the Comprehensive
Source Database ;P)

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.

> And I don't see how having automake in 7 different packages instead 
> of seven slots under the same package makes it any less complex.

It WILL make it easier. The whole slot handling could be dropped off
(makes the code much easier) and the problems with slots simply 
would not exist. 
 
> How is having a depend on =sys-devel/automake-1.4* or sys-devel/automake:1.4 
> any more complex than a depend on a separate packages named 
> sys-devel/automake-1.4 ? 

What if now comes an 1.4.99 which is totally incompatible with the
other 1.4.* ? What do you do now ? 

Drop that 1.4.99 ? 
Give it another version, ie. some 1.5.* ?
Touch all depending patches to exclude 1.4.99 ? 

> There are actuallly packages in the tree that don't care which version 
> of automake is in use (at least according to there ebuilds). Now they 
> just depend on sys-devel/automake. With your brilliant solution they 
> would have to depend on || ( sys-devel/automake-1.4 
> sys-devel/automake-1.5 ... ).

Simply add an virtual for that ? 

BTW: (beside rare cases), ebuilds normally sould have no variants
in their dependencies - this should be left to the virtuals, IMHO.

> > No idea, why the responsible Gentoo-devs didn't just give
> > those incompatible packages different names, especially on
> > their own packages. AFAIK, java-config is made by Gentoo.
> > It would be trivial, just to call the 2.x version something
> > like java-config-2 ... perhaps too simple for them ?
> 
> It still doesn't change the problem that if they have different 
> files with the same name they need to install it in different 
> places. That problem is just the same whether in slots or separate 
> packages.

Right. But that argument is neither for slots nor against. 

> [SNIP]
> > As someone else already that: one of the problems with slots.
> > They don't work well on cleanup. I wonder if anybody ever thought
> > about that when slots were introduced.
> 
> --depclean does actually remove unneeded slots now for packages 
> not in system or world.

Well, I didn't prove it by myself - just took the input from this 
list, where people stated it would NOT do it cleanly.

> By removing slotting you take away flexibility and make things 
> in a source distribution harder.

What flexibility do I take away exactly ?
And what exactly gets harder ? 


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

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

[Kent Fredric]

On 6/9/07, Enrico Weigelt <weigelt@metux.de> wrote:
>
> What flexibility do I take away exactly ?
> And what exactly gets harder ?
>

Automated building of dependant packages

Gentoo has a collection of magic script that do make this nice for us.

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)

I remeber the days of Java1.4 -> Java1.5 migration headaches before
they slotted it and created java-confing system to get around it,  boy
did it take its sweet ass time getting there ( cos there were at least
100 apps which needed 1.4 instead of 1.5, and if you compiled one of
those with 1.5 instead of 1.4, which the ebuild never expected to have
happen, due to being authored before 1.5's release , ... the entire
heirachy would break, and you'd give up and simply remove _ALL_ of
java just to keep sane, but thats not gentoos fault exactly, blame a
multitude of upstream javaheads for that )

As for gtk2-0.1 vs gtk-2.0.1, the latter is clearly a more logical
version number.
gtk2.0.1 is invalid (no - to separate version from subversion ), and
on top of that
if it was called gtk2 instead of gtk-2, it would need a separate
folder, and a completely different set of configs,

it was bad enough when php4 & php5 were different applications. Im so
glad they slotted that. Its just annoying still that due to the
massive magnitude of apps for php4/5 that they have to have a separate
_TOP_LEVEL_ dir for them all.



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

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

[Enrico Weigelt]

* Kent Fredric <kentfredric@gmail.com> wrote:
> On 6/9/07, Enrico Weigelt <weigelt@metux.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.


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

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

[Kent Fredric]

On 6/9/07, Enrico Weigelt <weigelt@metux.de> wrote:
> * Kent Fredric <kentfredric@gmail.com> wrote:
> > On 6/9/07, Enrico Weigelt <weigelt@metux.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@gma.com"[(2*x)..(2*x+1)]}'
-- 
gentoo-user@gentoo.org mailing list

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

[Kent Fredric]

On 6/9/07, Kent Fredric <kentfredric@gmail.com> wrote:
> On 6/9/07, Kent Fredric <kentfredric@gmail.com> wrote:
> >
> > 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? )
> >
>
> Just replying to myself here.
>
> ] sys-devel/automake
>      Available versions:
>         (1.4)   1.4_p6
>         (1.5)   1.5
>         (1.6)   1.6.3
>         (1.7)   1.7.9-r1
>         (1.8)   1.8.5-r3
>         (1.9)   1.9.6-r2
>         (1.10)  1.10
>
> screw making a seperate package for each of those.
> Screw being the poor bastard who parsed the package names from the
> ebuild titles to make it work :S
>

Oh yeah, bags not doing linux-gazette or app-doc/phrack
Some of us have lives to get on with :P



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

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

[Enrico Weigelt]

* 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

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

[Kent Fredric]

On 6/9/07, Enrico Weigelt <weigelt@metux.de> wrote:
> * 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.


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

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 (this does
give the added benefit that if somebody else were to create a PHP
engine they could just jump into the virtual, or if one day php5 were
to be  /fully/ backwards compatible with php4 its  version could be
dumped into the php4 virtual and allow people to upgrade .. )
So either way you look at it, its just a case of /where/ the slotting
occurs, not whether or not it occurs.

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

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

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

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

Which IMO would produce horror stories you could tell to your children,
especially if many other packages currently utilizing slotting were to
go that way.




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

> > 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.


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]

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


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'

how do we make this easy to use?

Heres my proposition, and thats slot-files.
Like virtuals, but on a per-package level. (Cos virtuals are really
designed to handle multiple packages that provide the same function,
not one package which produces multiple different functions )

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.

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.

Now these are just my suggestions to how we could fix your oppositon
of the current slotting system, and perhaps improve gentoos slot
function without breaking it for all existing things.

Your thoughts & suggestions appreciated.


*1 http://devmanual.gentoo.org/general-concepts/slotting/index.html
-- 
Kent
ruby -e '[1, 2, 4, 7, 0, 9, 5, 8, 3, 10, 11, 6, 12, 13].each{|x|
print "enNOSPicAMreil kdrtf@gma.com"[(2*x)..(2*x+1)]}'
-- 
gentoo-user@gentoo.org mailing list

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

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

On Saturday 09 June 2007 08:44:23 Kent Fredric wrote:
> %=sys-devel/automake-1.9
> %<=sys-devel/automake-1.9
> %>=sys-devel/automake-1.9
>
> 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'

That's what EAPI bumps are meant to solve.

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Enrico Weigelt]

* Kent Fredric <kentfredric@gmail.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@gentoo.org mailing list

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

[Bo Ørsted Andresen]

[-- Attachment #1: Type: text/plain, Size: 6042 bytes --]

On Friday 08 June 2007 14:46:54 Enrico Weigelt wrote:
> > Well, they still are different versions under the same packages
> > from the same projects.
>
> Evolutionarily yes, technically no ;-P
> They're in fact very diffrent, but provide an very similar
> (almost the same) functionality.
>
> The problem is: upstream claims that newer evolutions steps
> were newer versions, Gentoo takes it as it is and runs into
> trouble, the attempt to fix this is slotting.

Wtf. Newer versions are newer versions. No matter if they are fully backwards 
compatible or not.

> If we simply would consider them as different packages,
> the whole story would be trivial. We just have to decide at
> which point a split has to be done. The whole complexity of
> slotting and the still unsolved problems (ie. cleaning up)
> could be dropped and dependency handling would be easy.

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. 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.

I *really* don't see how adding seven versions of automake as seven packages 
in seven dirs plus adding a virtual that's provided by all seven of those 
versions is easier than just having seven versions in the same package with 
different slots. 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).

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. At this point it would be 
pretty trivial to add both, however, the problem with that is backwards 
compatibility with older versions of portage itself. Profiles aren't 
versioned like ebuilds with an EAPI so there are no means to assure that 
people upgrade portage before getting profiles that are incompatible with 
older versions of portage.. Even today we still occasionally get bug reports 
from people who --sync with <portage-2.0.51 which aren't compatible with the 
current profiles (bug #114798)...

[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).

> > > Gentoo has an strange magic for handling that, called "Slots".
> > > They deeply break the linear version space. This makes handling
> > > very tricky and requires much additional complexity. Some of
> > > the other replies should make clear some prolems ...
> >
> > I have no idea what breaking 'the linear version space' means.
[SNIP]
> 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)? Do 
you *any* idea how many packages that would result in? It would be a 
maintenance nightmare. Keep in mind that CVS doesn't even support removing a 
package properly (with it's dirs).

[SNIP]
> > How is having a depend on =sys-devel/automake-1.4* or
> > sys-devel/automake:1.4 any more complex than a depend on a separate
> > packages named
> > sys-devel/automake-1.4 ?
>
> 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?

> Drop that 1.4.99 ?
> Give it another version, ie. some 1.5.* ?
> Touch all depending patches to exclude 1.4.99 ?

Huh?

[SNIP]
> > > No idea, why the responsible Gentoo-devs didn't just give
> > > those incompatible packages different names, especially on
> > > their own packages. AFAIK, java-config is made by Gentoo.
> > > It would be trivial, just to call the 2.x version something
> > > like java-config-2 ... perhaps too simple for them ?
> >
> > It still doesn't change the problem that if they have different
> > files with the same name they need to install it in different
> > places. That problem is just the same whether in slots or separate
> > packages.
>
> Right. But that argument is neither for slots nor against.

So that still leaves me without a clue about what problem making 
java-config-{1,2} different packages rather than slots would solve.

[SNIP]
> > --depclean does actually remove unneeded slots now for packages
> > not in system or world.
>
> Well, I didn't prove it by myself - just took the input from this
> list, where people stated it would NOT do it cleanly.

The ability to do that has been added rather recently.

> > By removing slotting you take away flexibility and make things
> > in a source distribution harder.
>
> 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. 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.

-- 
Bo Andresen

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Enrico Weigelt]

* Bo Ørsted Andresen <bo.andresen@zlin.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@gentoo.org mailing list

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

[Kent Fredric]

On 6/13/07, Enrico Weigelt <weigelt@metux.de> wrote:

> Okay, this isn't really about slots vs. no slots, but shows that
> slots are not necessary.
>
>
> cu

Well, IMO everything should be slotted 100% every version able to be
installed in parallel, and packages depend on version, and versions
with no depends are obviously not needed and cleaned out ,,, but we'll
have to agree to dissagree ;)


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