[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: S-lang availabe from my ftp site for testing



"Michael Alan Dorman wrote:"
> 
> In message <199605231518.LAA11356@access.netaxs.com>, Chris Fearnley writes:
> >upstream maintainer about this!) that I want to make sure I didn't miss
> >anything wrt .deb packaging.
> >-rw-------  1 cjf      general      5537 May 23 10:02 slang-0.99.31-1.diff.gz
> >-rw-------  1 cjf      general    262254 May 23 10:02 slang-0.99.31-1.tar.gz
> >-rw-------  1 cjf      general    276134 May 23 10:01 slang-dev-0.99.31-1.deb
> >-rw-------  1 cjf      general     62286 May 23 10:01 slang-lib09931-1.deb

The permissions are fixed now, sorry about that.

> Assuming that your file names reflect the information in the actual
> control file, then your setup is a bit at odds with what has been worked
> out as the best current solution for shared-lib packages.

It is at odds with the general case, but S-Lang is a special case.

>  1) the runtime-support package (with shared libs and anything else
> 	necessary for running pre-compiled programs, though hopefully not
> 	much other than that shared library) should have the package name
> 	PKGSONAME-VER, where:
> 
>      PKG is the package name,
> 	 SONAME is the soname of the library,
> 	 VER is the normal package version + debian revision info

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.

>  2) a developer-support package (with headers, examples, documentation)
> 	should have the package name PKGSONAME-dev-VER, with PKG, SONAME and
> 	VER being set as above.

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.

> This scheme has the big advantage that it allows a user to keep multiple
> versions of the runtime-support package installed simultaneously, so that
> she doesn't ever find herself in the position of having to chose between
> having package A (which depends on foo-1.4.5) or package B (which depends
> on foo-1.4.7), where foo1.4.5 and foo-1.4.7 are mutually exclusive.

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?

> There are a few other nuances (the -dev package usually both provides and
> conflicts with PKG-dev, so that you don't install two at once).  You
> might want to look at the control file info for libc5 and libc5-dev, for
> instance, since they were the initial testing ground for all of this.
> 
> I can't recommend strongly enough that you structure your packages this
> way---I know it's complicated and involved and nasty, but I also suspect
> that, given the people we had working on figuring this scheme out (Bruce,
> David Engel, Ian Jackson), there's not much more that can be done without
> losing important flexibility.

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.

Hmm, perhaps if S-Lang's C interface ever stabilizes, it would be
good to have the -dev package indicate the version in the package name.
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?

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?

Here's my dpkg -l report:
$ dpkg -l 'slang*'
Desired=Unknown/Install/Remove/Purge
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name            Version        Description
+++-===============-==============-============================================
ii  slang-dev       0.99.31-1      a C programming library - development kit
ii  slang-lib       0.99.23-1      S-Lang - a C programming library - shared ob
ii  slang-lib09931  0.99.31-1      A C programming library - shared library

Do Enjoy!

-- 
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: