Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Rob Browning]

I'm working on the packaging of 1.6 for Debian, and I wondered if
anyone would oppose dropping the minor revision number from guile's
working directory.  The argument against would be that it isn't as
specific and would prevent you from having two minor revisions of
guile installed in the same place at the same time, but you can't do
that anyway since their library, binary, etc. names would collide.

The argument in favor is that it means that any other guile "add-on"
packages that are guile version sensitive can place a symlink (or a
copy) of their .scm dir in share/guile/X.Y/ without having to worry
about the directory being yanked out from under them when the guile
package goes from 1.6.1 to 1.6.2.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Mikael Djurfeldt]

Rob Browning <rlb@defaultvalue.org> writes:

> I'm working on the packaging of 1.6 for Debian, and I wondered if
> anyone would oppose dropping the minor revision number from guile's
> working directory.  The argument against would be that it isn't as
> specific and would prevent you from having two minor revisions of
> guile installed in the same place at the same time, but you can't do
> that anyway since their library, binary, etc. names would collide.

Hmm... shouldn't the libraries from different minor versions of Guile
have different version numbers (bumbed between versions) and therefore
be possible to install in parallel?

Regarding the binary: How about using similar conventions as for
emacs: guile symlinked to guile1.6.1

Best,
Mikael


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Rob Browning]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

> Hmm... shouldn't the libraries from different minor versions of Guile
> have different version numbers (bumbed between versions) and therefore
> be possible to install in parallel?

I should have been more specific -- I meant the revision number here,
what we call the MICRO version.  i.e. 1.6.1 vs 1.6.2.  Across those
two, I wouldn't necessarily (if perhaps at all -- see other msg)
expect the library version numbers to change.

For example, imagine the release was just a documentation update.

> Regarding the binary: How about using similar conventions as for
> emacs: guile symlinked to guile1.6.1

Do we want to support multiple installed MICRO revisions?  i.e. do we
want it to be possible to install guile 1.6.1 and guile 1.6.2 side by
side?  I was presuming we didn't specifically care about that, but if
we do, we probably can, but the changes will be more substantial since
we'll also have to start versioning the name of libguile,
i.e. libguile-12.so so that the .so development and .la dynamic
linking files won't clobber each other.

For Debian at least I was packaging things for now so that you can
only have one guile-X.Y-dev package installed at a time.  To do
anything different would require more upstream changes (including the
above), and until/unless that happens, people should be able to get by
by just switching out the -dev packages.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Mikael Djurfeldt]

Rob Browning <rlb@defaultvalue.org> writes:

> Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:
> 
> > Hmm... shouldn't the libraries from different minor versions of Guile
> > have different version numbers (bumbed between versions) and therefore
> > be possible to install in parallel?
> 
> I should have been more specific -- I meant the revision number here,
> what we call the MICRO version.  i.e. 1.6.1 vs 1.6.2.  Across those
> two, I wouldn't necessarily (if perhaps at all -- see other msg)
> expect the library version numbers to change.

Well, that's what I meant as well.

> For example, imagine the release was just a documentation update.
> 
> > Regarding the binary: How about using similar conventions as for
> > emacs: guile symlinked to guile1.6.1
> 
> Do we want to support multiple installed MICRO revisions?  i.e. do we
> want it to be possible to install guile 1.6.1 and guile 1.6.2 side by
> side?  I was presuming we didn't specifically care about that, but if
> we do, we probably can,

Marius and you have to have the final say about this.

Without having thoroughly thought about it, I'd say it would be
useful to be able to install parallel micro versions, the reason being
that you may trust a certain micro version, but would like to do
development on another.

> but the changes will be more substantial since we'll also have to
> start versioning the name of libguile, i.e. libguile-12.so so that
> the .so development and .la dynamic linking files won't clobber each
> other.

Maybe that would be a great idea.  I've been trying to keep a
system-level production version of guile-1.4 installed under /usr/lib
in parallel with an experimental guile-1.7.0 under /usr/local/lib.

A real nuisance has been that the libtool-generated link flags contain
both -L /usr/lib and -L /usr/local/lib in a somewhat arbitrary order.
I tried to resolve this, but finally got so frustrated that I simply
moved away all libraries under /usr/lib while compiling guile-1.7.0...

> For Debian at least I was packaging things for now so that you can
> only have one guile-X.Y-dev package installed at a time.  To do
> anything different would require more upstream changes (including the
> above), and until/unless that happens, people should be able to get by
> by just switching out the -dev packages.

Are you sure, considering what I wrote above?

It seems to me that we'll have trouble as long as we don't include the
version in the library names...

Mikael


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Rob Browning]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

>> For Debian at least I was packaging things for now so that you can
>> only have one guile-X.Y-dev package installed at a time.  To do
>> anything different would require more upstream changes (including the
>> above), and until/unless that happens, people should be able to get by
>> by just switching out the -dev packages.
>
> Are you sure, considering what I wrote above?

Yes (depending on what you mean) because the -dev package on a Debian
system is the one that contains the .so links, so it dictates which
library you'll get when you say -lfoo if there's more than one
candidate available.

It won't help with your /usr/lib vs /usr/local/lib problem, though.
Putting the major number in the library name is how you'd have to fix
that.

Note that if you wanted (as you suggested above) to allow two micro
revisions to be installed in parallel for debugging, we'd have to go
so far as to put the full version into the library name,
i.e. libguile-12.0.1.so or similar, and I would argue fairly strongly
against that.  With the full version in the library name, all apps
compiled against guile would have to be recompiled when we make *any*
guile release, even just a micro revision.  It's possible you could
avoid that with symlink tricks or similar, but I'd be much more
comfortable, if we do anything, with just putting the soname in the
library name, and not planning to support parallel installs of micro
revisions.

Of course I don't actually have a good answer, other than "remove the
.so symlinks" (i.e. the -dev pkg on a debian system) to the question
of how on any given platform you can actually test/develop a minor
guile revision that's different from the one in /usr/lib when you also
have to use other foo-config tools that might insert -L/usr/lib into
random places on the gcc command line, but this is not a problem
specific to guile.  It's a broader foo-config/unix-model problem.

pkg-config may be able to help here, and gcc could fix the problem if
it supported --push-flags and --pop-flags args, but AFAIK neither fix
is available yet.  We might be able to solve this problem by putting
all our libs into /usr/lib/guile/VERSION/ so that you have to specify
a -L flag to get anything, but then you've got the ld.so.conf problem,
and I agree with Marius that we're probably better off sticking with
the normal unix mechanisms and perhaps trying to help come up with a
better answer "upstream" if possible.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Rob Browning]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

> Without having thoroughly thought about it, I'd say it would be
> useful to be able to install parallel micro versions, the reason being
> that you may trust a certain micro version, but would like to do
> development on another.

If I understand correctly, then when you install the new "development"
micro version, it'll have a libguile with the same soname as the
"trusted" version, and at that instant, all apps will switch to using
the new "untrusted" lib because that's the one ldso will prefer
version-wise (that's presuming the new libguile doesn't just clobber
the old one if the micro version wasn't changed).

If I'm right about that, then are there any other arguments in favor
of not dropping the micro revision from things like the share
directory name, or would you be OK with it?

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Mikael Djurfeldt]

Rob Browning <rlb@defaultvalue.org> writes:

> Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:
> 
> > Without having thoroughly thought about it, I'd say it would be
> > useful to be able to install parallel micro versions, the reason being
> > that you may trust a certain micro version, but would like to do
> > development on another.
> 
> If I understand correctly, then when you install the new "development"
> micro version, it'll have a libguile with the same soname as the
> "trusted" version, and at that instant, all apps will switch to using
> the new "untrusted" lib because that's the one ldso will prefer
> version-wise (that's presuming the new libguile doesn't just clobber
> the old one if the micro version wasn't changed).
> 
> If I'm right about that,

You are.

> then are there any other arguments in favor of not dropping the
> micro revision from things like the share directory name, or would
> you be OK with it?

I have no other argument.  Also, it is "OK" with me to do as you want,
because I haven't the time to think about it.

But if you ask my current uninformed opinion, and given the current
poor status of UNIX tool for handling this kind of dependencies, I'd
say I prefer separating micro versions and recompiling things between
micro version releases. :)

Best regards,
Mikael


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Rob Browning]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

> I have no other argument.  Also, it is "OK" with me to do as you want,
> because I haven't the time to think about it.
>
> But if you ask my current uninformed opinion, and given the current
> poor status of UNIX tool for handling this kind of dependencies, I'd
> say I prefer separating micro versions and recompiling things between
> micro version releases. :)

Well it certainly would fix the problem in some sense, but unless
we're going to make guile "Depends: gcc", and switch to a "compile on
install" packaging arrangement (don't think I haven't considered that
-- actually having gcc around all the time might open up some
"interesting" compilation options), I suspect we might have a revolt
from the users tracking Debian unstable if all guile packages broke
with every minor release :>

Though I guess if we put the full version in the lib names and in
*everything* else (like libguile-1.6.1.so,
libguile-srfi-srfi-4-v-1.6.0.so etc.) then we could just eat a lot of
disk space rather than break things with new releases, but I also
suspect that the first time one of the other Debian maintainers
noticed that they had all of the

  guile-1.6.1
  guile-1.6.2
  guile-1.6.3
  guile-1.8.1
  guile-1.8.2

packages installed at the same time (due to leftovers), I might have
to think fast if I wanted to avoid a good trouncing :>

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[tomas]

On Wed, Nov 13, 2002 at 02:33:05PM -0500, Mikael Djurfeldt wrote:
> Rob Browning <rlb@defaultvalue.org> writes:
> 

[...]

> But if you ask my current uninformed opinion, and given the current
> poor status of UNIX tool for handling this kind of dependencies, I'd
> say I prefer separating micro versions and recompiling things between
> micro version releases. :)

...which of course kills the idea of a binary distribution, in practical
terms. You can't install package X without upgrading library Y by two
micro steps -- otoh the vital package Z depends too strongly on micro
(probably it's not serious, but do you know?) version. You see things of
this kind in Debian. OTOH distros are becoming so huge that it's more
and more of a pain to create frozen self-consistent `versions'.

What to do?

(I think Rob's fight to ``hide'' micro version as much as possible
is a laudable step in this direction).

Regards

-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Andreas Rottmann]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

> Rob Browning <rlb@defaultvalue.org> writes:
> 
> > I'm working on the packaging of 1.6 for Debian, and I wondered if
> > anyone would oppose dropping the minor revision number from guile's
> > working directory.  The argument against would be that it isn't as
> > specific and would prevent you from having two minor revisions of
> > guile installed in the same place at the same time, but you can't do
> > that anyway since their library, binary, etc. names would collide.
> 
> Hmm... shouldn't the libraries from different minor versions of Guile
> have different version numbers (bumbed between versions) and therefore
> be possible to install in parallel?
> 
No, shared library SONAME should only change when a
binary-incompatible change happens, which shouldn't be the case with
stable guile versions, or am i wrong here?

> Regarding the binary: How about using similar conventions as for
> emacs: guile symlinked to guile1.6.1
> 
Hmm, I wonder if people really want different minor versions of
the same major version of guile installed.

Regards, Andy
-- 
Andreas Rottmann         | Dru@ICQ        | 118634484@ICQ | a.rottmann@gmx.at
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Neil Jerram]

>>>>> "Rob" == Rob Browning <rlb@defaultvalue.org> writes:

    Rob> I'm working on the packaging of 1.6 for Debian, and I wondered if
    Rob> anyone would oppose dropping the minor revision number from guile's
    Rob> working directory.

Assuming you mean micro, this sounds OK to me.  My understanding is
that the API doesn't change within a stable series, so not allowing
multiple revisions to be installed at the same time makes sense.

        Neil




_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Any opposition to changing share/guile/X.Y.Z to share/guile/X.Y?

[Rob Browning]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Assuming you mean micro, this sounds OK to me.  My understanding is
> that the API doesn't change within a stable series, so not allowing
> multiple revisions to be installed at the same time makes sense.

Yeah, sorry, I'm getting the libtool nomenclature and our nomenclature
confused.  I meant micro in our terms, revision in theirs -- that's
why I said "minor revision" which was quite confusing for those
actually paying attention :>

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel