On 10/23/2012 12:52 PM, Kalev Lember wrote:
> 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
>
What you describe here is my original proposal:)
Yes, both packages are parallel installable now. And the effort isn't that great
really. Whether it is the right thing to do, I don't think the answer is clear
as well (see Toshio's and Adam's answers down the thread). And further, I think
that such changes are not invasive at all, as they affect only the old versions
of stuff.
Guile2 package would require some scripts and the binary to be renamed and then
symlinks would have to be created, which would cause more mess IMO. Creating a
compat package and then updating guile simply seems more "natural" to me. As far
as the patches for the dependent packages are concerned, I'd probably be able to
patch all of them myself, as the patches are really quite simple (a lot of
mechanic work though).
Anyway, I think that neither of those solutions is far superior in any way.
Maybe I could drop all the renaming in the compat package and make it conflict
with guile-devel, but that there seems to be no agreement on whether it is or is
not a good solution.
So, if nobody really objects, I'm going keep the current solution.
Cheers,
--
Jan Synacek
Software Engineer, BaseOS team Brno, Red Hat
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
