slang library issues
Of course, in all this, I only speak as:
1) an interested user who would love to use a well-packaged slang to
package up Jed and dosemu and a couple of other things, and
2) someone who maintains one of the essential shared lib packages, and
3) probably the only person who has re-read the exchange on debian-devel
last Nov/Dec when this stuff was all being hammered out.
As such, I can't tell anyone what to do, and I don't speak for the
project. But I do feel very strongly about this.
In message <[🔎] 199605260800.EAA16255@syntropy.netaxs.com>, Chris Fearnley writes:
>It is at odds with the general case, but S-Lang is a special case.
That John Davis hasn't settled on a ABI yet doesn't imply that there is
any reason to ignore precedent, especially since precedent solves all of
your problems more than adequately.
What you propose to introduce seems to me to be gratuitously different,
and I will argue against it at every opportunity.
>The soname is 0.99.31. I thought it would be foolish to name the
>package slang-lib09931-0.99.31-1.deb. See below.
Well, that's still not consistent with the standards that have been
more-or-less agreed upon by everyone else developing shared library
packages.
By those standards, the correct name would be slang0.99.31-0.99.31-1.deb.
Unwieldy, yes, but that's why we have dselect and/or tab completion.
>OK, I remember this now. But S-Lang is exceptional in that the C
>interface changes every release or two, i.e., every couple of months.
>Hence each new version produces incompatible libraries with previous
>versions.
Incompatible libries is exactly what the scheme that has been agreed upon
is designed to accomodate. Cleanly. Reliably. There's _nothing_
special about slang in that respect.
My problem, what causes me to write these long messages, is the fact that
you seem to me to be doing a halfway job of following that
standard---and, speaking for myself, that irritates me to no end because
it produces gratuitous inconsistencies.
It is just those inconsistencies that have kept me from packaging jed
using your older package---it wasn't worth my while to have to worry
about what headaches an upgrade might produce, etc. Unfortunately, it
seems like that still may be the case.
>This is only /necessary/ for the runtime libs, no? I mean the -dev
>package doesn't /need/ this level of flexibility? I suspect this was
>done for consistency vs. a real need, no?
Well, without it there would _never_ be a chance of supporting multiple
simultanous development environments, but I don't think anyone is
seriously considering doing that, so yes, it is merely for consistency.
To quote you, though:
>Consistency is good!
>I've done this for the runtime libs. I have slang-lib0 (which is version
>0.99.24) and my new slang-lib09931-1 happily coexisting on my system
right now. But I'm missing the importance for versioning the name of the
>-dev package, right now. And the most package (depends on slang-lib0)
>still works. So I'm pretty confident that I've done the runtime libs
>right.
But the packages ignore a fairly-well established naming convention, for
no appreciable reason. That's not, IMAO, "right"
>Consistency is good! But right now that would mean Conflicts and Replaces
>lines for each incompatible version. That would make for a very large
>control file. A real ugly mess, IMO. I think the -dev package guidelines
>should /recommend/ following your outline, but S-Lang is too volatile
>for such complexity. Is there some way to simplify this that I'm missing?
You need only have each -dev package both provide and conflict with
slang-dev, and it all works. Looking at the control files for libc5 or
ncurses3.0 packages would have illustrated this.
I find myself inordinately irritated at your obstinate refusal to do your
research. If you would look at _much_ more complex and _significantly_
more essential packages than slang (libc, ncurses), you would find that
_we've already solved the problems_.
>I fully agree with the runtime libs aspect of your note and I have
>implemented it. Though I see that maybe I should have named the
>package slang-lib0.99.31-0.99.31-1.deb or slang-lib09931-0.99.31-1.deb
>or somesuch. Ugly, but more consistent. Any suggestions on encoding
>the soname of "0.99.31" into the package name would be welcome?
Not to seem too terribly pedantic, but normally shared libraries don't
include -lib.
Mike.
--
"Don't let me make you unhappy by failing to be contrary enough...."
Reply to: