DevHeads.net

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

Hello all,

I've created a review request for compat-guile1.8:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=868263" title="https://bugzilla.redhat.com/show_bug.cgi?id=868263">https://bugzilla.redhat.com/show_bug.cgi?id=868263</a>

Once the compat package lands in rawhide, I will leave some time for the
transition (I may work on the required patches if time allows me). After that,
guile (now version 1.8) will become 2.0.x.

I've already tried patching a few packages and there seem to be no real
problems, unlike patching the old apps for the new guile.

Affected packages:
aisleriot
autogen
coot
denemo
drgeo
freehoo
freetalk
geda
gnubik
gnucash
gnurobots
gnutls
graphviz
libctl
libgeda
lilypond
mdk
rumor
TeXmacs
trackballs
xbindkeys

Cheers,

Comments

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

By Kalev Lember at 10/23/2012 - 05:15

On 10/23/2012 08:51 AM, Jan Synacek wrote:
Hello Jan,

Very cool. The lack of guile 2.0 has been keeping Aisleriot updates back
for several Fedora releases now.

Are you planning to make the 2.0 version available for F18 as well?

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

By Jan Synacek at 10/23/2012 - 05:42

On 10/23/2012 11:15 AM, Kalev Lember wrote:
I'm quite hesitant to update F18 as well. I mean, it would be nice, but I'm not
sure if all can be probably patched and tested in time. If only I had done this
a few weeks earlier..:)

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

By Kalev Lember at 10/23/2012 - 05:55

On 10/23/2012 11:42 AM, Jan Synacek wrote:
I agree, updating 21 packages is a bit too much at this point in F18
schedule.

However, a way to make this work for F18 would be creating a parallel
installable guile20 package. So instead of what you are planning now:

guile-2.0.x
compat-guile1.8-1.8.x

We'd have:
guile20-2.0.x
guile-1.8.x

This way no apps need to be updated for the guile -> compat-guile1.8
transition. Instead, they could be ported to guile20 at their own pace
and there wouldn't have to be a flag day for switching all of them over
at once.

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

By Jan Synacek at 10/23/2012 - 06:12

On 10/23/2012 11:55 AM, Kalev Lember 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..

Cheers,

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

By Kalev Lember at 10/23/2012 - 06:52

On 10/23/2012 12:12 PM, Jan Synacek wrote:
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:

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:
<a href="http://packages.debian.org/sid/amd64/guile-1.8/filelist" title="http://packages.debian.org/sid/amd64/guile-1.8/filelist">http://packages.debian.org/sid/amd64/guile-1.8/filelist</a>
<a href="http://packages.debian.org/sid/amd64/guile-2.0/filelist" title="http://packages.debian.org/sid/amd64/guile-2.0/filelist">http://packages.debian.org/sid/amd64/guile-2.0/filelist</a>

Conflicting -dev package:
<a href="http://packages.debian.org/sid/amd64/guile-1.8-dev/filelist" title="http://packages.debian.org/sid/amd64/guile-1.8-dev/filelist">http://packages.debian.org/sid/amd64/guile-1.8-dev/filelist</a>
<a href="http://packages.debian.org/sid/amd64/guile-2.0-dev/filelist" title="http://packages.debian.org/sid/amd64/guile-2.0-dev/filelist">http://packages.debian.org/sid/amd64/guile-2.0-dev/filelist</a>

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

By Jan Synacek at 10/25/2012 - 03:55

On 10/23/2012 12:52 PM, Kalev Lember wrote:
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,

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

By Adam Williamson at 10/25/2012 - 18:49

For the record, I don't object. I think my way is The Right Way, as we
all do ;), but you're correct that there really doesn't appear to be a
consensus, and it doesn't seem like most people really _care_. So maybe
this should just be left to packager discretion, I dunno.

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

By Miroslav Lichvar at 10/23/2012 - 09:44

On Tue, Oct 23, 2012 at 12:52:47PM +0200, Kalev Lember wrote:
So both new and old guile scripts need to be patched to call
the right binary? Or is there a symlink created?

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.

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.

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

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

By Kalev Lember at 10/24/2012 - 05:57

On 10/23/2012 03:44 PM, Miroslav Lichvar wrote:
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.

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.

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.

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

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

By Toshio Kuratomi at 10/23/2012 - 15:17

On Tue, Oct 23, 2012 at 03:44:11PM +0200, Miroslav Lichvar wrote:
at sonme point we should probably clarify that section.... I can't remember
now where we wanted the line to be drawn. The fact that htis has been done
in SUSE and that porting is proceeding here seems to indicate that we
wouldn't want a Conflicts in this case.

-Toshio

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

By Adam Williamson at 10/23/2012 - 17:58

That's funny, I was going to say the opposite...I think we should
clarify it to say that in the cases where it makes sense to have a
libfoo-compat package, there's no need to bend over backwards to try and
make libfoo-devel and libfoo-compat-devel be parallel installable,
because there's just no important use case for it. There is no reason
you'd need to compile one code base against two different versions of
the same library, so there's no case where you would need to have both
-devel packages installed simultaneously.

I think we should be strict about trying not to package multiple majors
of the same library wherever possible, but where it's pretty much
unavoidable, I think it's perfectly fine for the -devel packages to
conflict. In fact I think it's better to leave them conflicting than to
hack them up with patches to make them not conflict; that's always going
to be a hack job, nothing clean. The library thinks it's called libfoo,
not libfoo2 or libfoo-compat. I think the guidelines should reflect
this...they should explicitly say that a -devel package conflict is fine
and indeed recommended in the specific case of packaging multiple majors
of a single library.

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

By Toshio Kuratomi at 10/23/2012 - 19:25

On Tue, Oct 23, 2012 at 02:58:28PM -0700, Adam Williamson wrote:
-Toshio

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

By Adam Williamson at 10/23/2012 - 19:43

On Tue, 2012-10-23 at 16:25 -0700, Toshio Kuratomi wrote:
Well, I don't mind doing that, but I'd like to be sure there's a broad
consensus that this is the way to go first. I don't think 'duelling
drafts' is the best way to decide on what direction to go; I'd rather
make sure we agree on the direction first, and use the drafting process
simply to refine how we express that direction.

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

By Bill Nottingham at 10/24/2012 - 17:13

Adam Williamson (<a href="mailto: ... at redhat dot com"> ... at redhat dot com</a>) said:
It causes problems for people who build things outside of chroots with
straight rpmbuild, though, if they need to ever build different things
with different buildreqs (even as test builds).

Admittedly, we like to encourage people to use mock, but people will still
hit this.

Bill

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

By Kevin Kofler at 10/27/2012 - 00:45

Bill Nottingham wrote:
It also breaks building things directly from source, including as a
developer. We've had this issue with kdelibs3-devel vs. kdelibs4-devel,
where upstream didn't support parallel installation of -devel at all, and I
hacked things up to get that going exactly because of that. It would have
been really painful for developers of KDE software (including me!) to not be
able to have both -devel packages installed at the same time. You don't need
both for the same software, but a developer works on more than one piece of
software at a time.

And then there's also the case where something wants to build a subpackage
against, say, Qt 3 and another against Qt 4, we've had that case too (more
than once). And even one extreme case where gnash-klash was building the
Konqueror plugin (the KPart) against kdelibs 4 and the actual viewer
(embedded using XEmbed) against kdelibs 3, so it really needed both as a BR,
until the KDE 4 port of the viewer started working.

Conflicts should really only be a last resort, ESPECIALLY for libraries and
their -devel packages.

Kevin Kofler

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

By Adam Williamson at 10/27/2012 - 02:16

On Sat, 2012-10-27 at 06:45 +0200, Kevin Kofler wrote:
I've seen messy cases like that too. The kdelibs one sounds like a pain,
but for toolkits like GTK+ and Qt it seems a pretty established standard
that they're written to be parallel installable upstream because you'll
never get the whole world to change from one to the next overnight. So
those really aren't a problem.

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

By Adam Williamson at 10/24/2012 - 17:25

On Wed, 2012-10-24 at 17:13 -0400, Bill Nottingham wrote:
I know. I said 'important' use cases, I believe. =)

I just don't think that, overall, it's better to hack up a library's
build scripts and pkgconfig file and header locations and all the rest
of it than it is to tell people 'just flip which one you have installed
with yum when you really need to'. 'yum remove libfoo-devel', 'yum
install libfoo-compat-devel' is not a complex operation. If you really
have to do it all the time you could easily alias it to something even
shorter...