HEADS-UP: Transition to guile-2.0.x and a new compat-guile1.8 package

[Kalev Lember]

On 10/23/2012 03:44 PM, Miroslav Lichvar wrote:
> On Tue, Oct 23, 2012 at 12:52:47PM +0200, Kalev Lember wrote:
>> Parallel installable guile interpreters:
>> http://packages.debian.org/sid/amd64/guile-1.8/filelist
>> http://packages.debian.org/sid/amd64/guile-2.0/filelist
>
> So both new and old guile scripts need to be patched to call
> the right binary? Or is there a symlink created?

Looks like they are using alternatives to create the /usr/bin/guile
symlink. I don't know enough of guile to take a position if it's
something we should do in Fedora as well.


> Jan was proposing this approach too, but I thought if some packages
> need to be patched to use the 1.8 guile paths, why not make one step
> further and patch also the paths used in building. At least, when the
> maintainers of the old packages prepare the patches, they can make
> sure if the packages still work correctly.

I wouldn't be so sure everyone is up to this. A lot of package
maintainers just don't know enough of autotools to change even simple
things like this.


> Our packaging guidelines seem to allow (but discourage) conflicts with
> compat devel packages, if you think this will be a lot of unnecessary
> work, I'm ok with the conflict.

Let's take a step back for a moment. The reason why I am arguing for
less obtrusive changes is to find a way to land this in F18 as well. If
all the packages that use guile need patching, then it's very unlikely
to land in F18; like Jan said it's too late for this. But if we can
figure out a way to get parallel installable guile 1.8 and 2.0 so that
1.8 packages don't need patching, then I think it can make it to F18 as
well.


> FWIW, the OpenSuse packages don't seem to have the conflict and their
> libguile1-devel package has the aclocal file renamed to guile1.m4.

Do you know how they are handling the /usr/bin/guile symlink issue?


-- 
Kalev