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

Kalev Lember kalevlember at gmail.com
Tue Oct 23 10:52:47 UTC 2012


On 10/23/2012 12:12 PM, Jan Synacek wrote:
> This is what I had originally in mind. After trying to realize this idea and
> consulting it with the maintainer (I'm a comaintainer of guile), it didn't seem
> right. The problem is that a lot of things have to be renamed, including some
> autotools macros, and that creates a lot of mess long term (if it was done the
> the new package). With the compat package however, this are renamed as well, but
> it's the old stuff and then you can only slightly patch (mainly spec, no code
> changes needed) the old apps so they compile and run and don't have to worry
> about future changes. After guile is upgraded to 2.0.x, you can slowly start
> porting as well.
> 
> Huh, I hope my point is clearly visible in my slightly complicated message..

Oh, I see -- are you trying to make guile 2.x and guile 1.8.x -devel
packages parallel installable?

I am not sure it's worth the effort. Or more bluntly, I am not even sure
it's the right thing to do. E.g. something like the following (from
compat-guile1.8 spec file) strikes me as unusual and can cause a lot of
churn in dependent packages:

> ac=${RPM_BUILD_ROOT}%{_datadir}/aclocal/guile1.8.m4
> sed -i -e 's|,guile|,guile1.8|g' $ac
> sed -i -e 's|guile-tools|guile1.8-tools|g' $ac
> sed -i -e 's|guile-config|guile1.8-config|g' $ac
> sed -i -e 's|GUILE_PROGS|GUILE1_8_PROGS|g' $ac
> sed -i -e 's|GUILE_FLAGS|GUILE1_8_FLAGS|g' $ac
> sed -i -e 's|GUILE_SITE_DIR|GUILE1_8_SITE_DIR|g' $ac
> sed -i -e 's|GUILE_CHECK|GUILE1_8_CHECK|g' $ac
> sed -i -e 's|GUILE_MODULE_CHECK|GUILE1_8_MODULE_CHECK|g' $ac
> sed -i -e 's|GUILE_MODULE_AVAILABLE|GUILE1_8_MODULE_AVAILABLE|g' $ac
> sed -i -e 's|GUILE_MODULE_REQUIRED|GUILE1_8_MODULE_REQUIRED|g' $ac
> sed -i -e 's|GUILE_MODULE_EXPORTS|GUILE1_8_MODULE_EXPORTS|g' $ac
> sed -i -e 's|GUILE_MODULE_REQUIRED_EXPORT|GUILE1_8_MODULE_REQUIRED_EXPORT|g' $ac

The two -devel packages could just as well have explicit Conflicts set
to make sure they can't be installed at the same time; I don't think
it's important to hack them up to make them parallel installable, if it
involves such invasive changes.

What really matters is that end users can have 1.8 and 2.0 interpreter
and libraries installed at the same time. Not -devel packages; these are
mostly just used within koji for building binary packages.

This also appears to be what Debian is doing.

Parallel installable guile interpreters:
http://packages.debian.org/sid/amd64/guile-1.8/filelist
http://packages.debian.org/sid/amd64/guile-2.0/filelist

Conflicting -dev package:
http://packages.debian.org/sid/amd64/guile-1.8-dev/filelist
http://packages.debian.org/sid/amd64/guile-2.0-dev/filelist

-- 
Hope this helps,
Kalev


More information about the devel mailing list