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

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



Ian (or anyone), does the Guidelines document currently discuss the
accepted way of packaging shared libraries, along with the rationale
behind it?

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

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.

 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

 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.

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.

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.

Mike.
--
"Don't let me make you unhappy by failing to be contrary enough...."


Reply to: