Re: Guile 1.3 == SO 4
On Sat, Nov 14, 1998 at 07:40:10PM +0000, James Troup wrote:
> firstname.lastname@example.org (Ole J. Tetlie) writes:
> > *-James Troup <email@example.com>
> > |
> > | David Welton <firstname.lastname@example.org> writes:
> > |
> > | > If it is not compatible, why put symlinks?
> > |
> > | They're not. I got scwm working again by putting a compat symlink
> > | .so.3 -> .so.4.
> > Because one program _seems to_ work you assume that you know better
> > than the upstream?
> Say what? I never claimed to know better than upstream, I do seem to
> know more about the _Debian_ guile3 packages than the current
> ``maintainer'' though, which scares me.
As the "maintainer", I've never said that I knew much about guile.
You are more than welcome to take it over. I have done my best to try
and get the package in shape for slink, and have tried to accept
solutions and advice. This is an ongoing process, and something that
takes place in my free time. I'm sure this is the case for lots of
packages. I'm sorry of this frightens you, but it's the way things
> Programs in debian linked against libguile.so.3 were using a guile
> 1.3 snapshot, and *not* guile 1.2. As far as I know and can see,
> guile 1.3 has not changed that much since the date of the snapshot.
> David didn't say anywhere that upstream had explicitly claimed the
> contrary. Don't go with compat symlinks, if you want, but please,
> someone fix the damn package.
Upstream changed the SO number. As I have stated in the past, you are
welcome to take this issue up with him. His email address is
> I would really love to see this _sick_ habit of FUBARing library
> packages, which some maintainers seem to think is acceptable practice,
> end. If a library changes in an incompatible way (soname change or
> recompile with another library or whatever), the package name has to
> change. It's as simple as that. Anything less makes us look
> incredibly shoddy. I *don't* expect to upgrade a package with the
> debian package management system and have it break several other
> unrelated, and possibly critical applications on the system with *no*
Then maybe you shouldn't be using unstable. As far as 'unrelated' -
it's obviously related if it *depends* on it.
*I* am sick of these offhanded remarks about 'sick practices',
"maintainers", so on and so forth. They have *no* technical merit
whatsoever. I have better things to do than listen to these kinds of
So, what needs to be done to *fix* things, instead of just
My take on things is this:
Jim B. was releasing guile snapshots to the development community for
a while, which were just taht, snapshots. Karl H, apparently thought
they would be a good thing to have in Debian, and given all the other
alpha and beta software we have, there was certainly nothing wrong
with this reasoning. Now, we have a stable Guile release, which is
not a snapshot, but instead intended for general public consumption.
Seemingly, Jim bumped the SO number before releasing it as 1.3. From
his point of view, I think this is all fairly reasonable.
Now, there are a few packages in slink which depend on guile1.3, and
they probably ought to be recompiled with the new package. The
tguile (which can be removed, afaik)
I will send some email to the maintainers of these packages if I
haven't heard from them soon.
guile-scsh is one of Karl's. Would anyone like to have it?
David Welton http://www.efn.org/~davidw
Debian GNU/Linux - www.debian.org