Re: slang library issues
"Michael Alan Dorman wrote:"
>
> 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.
I don't mind the length, it's the redundancy that bothers me. But I
think I can accept it. Anyone see a better way than this version
stuttering?
> >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.
I think that I had and have solved the upgradeability issues. I think the
naming issues are/were not show-stoppers. In a few cases, the unwritten
conventions that you advocate are improvements. And so I will
tentatively adopt them.
> >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.
Aha, I looked, but didn't see. Thanks, for pointing that possibility out.
> 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_.
First, the first cut at S-Lang (0.99.23) was done just as the shared
lib conventions were being designed. Secondly, my second release is on
my ftp site, not yet submitted to the project. I'm cautious and wanted
some feedback before committing another version to the archive. Finally,
there is no written specification for the naming of shared libraries
(none that I could find anyway - I reread the Guidelines cover to cover
before putting S-Lang on my ftp site). I overlooked some options for
nameing things because I thought I might overcome some problems. Now I
see that my solutions were probably phantoms, and so a more consistent
approach is appropriate. Thanks for sharing your thoughts (though you
could have speculated less on my reasons :)
I put another release at ftp://ftp.netaxs.com/people/cjf/debian
$ ls -l
-rw-rw-r-- 1 cjf general 259197 May 28 04:03 slang0.99-31.tar.gz
-rw-rw-r-- 1 cjf general 5814 May 28 04:06 slang0.99.31-0.99.31-1.diff.gz
-rw-rw-r-- 1 cjf general 264208 May 28 04:06 slang0.99.31-0.99.31-1.tar.gz
-rw-rw-r-- 1 cjf general 62354 May 28 03:59 slang0.99.31-1.i386.deb
-rw-rw-r-- 1 cjf general 149106 May 28 04:01 slang0.99.31-dev-0.99.31-1.i386.deb
Now maybe you'll feel comfortable enough to test it and tell me if the
shared library even works. And did I include all the header files needed
for jed and slrn?
> >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...."
Not a chance :)
--
Christopher J. Fearnley | Linux/Internet Consulting
cjf@netaxs.com | UNIX SIG Leader at PACS
http://www.netaxs.com/~cjf | (Philadelphia Area Computer Society)
ftp://ftp.netaxs.com/people/cjf | Design Science Revolutionary
"Dare to be Naive" -- Bucky Fuller | Explorer in Universe
Reply to: