Re: S-lang availabe from my ftp site for testing
Michael Alan Dorman writes ("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?
No, there isn't.
...
> 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'm not convinced that you want to encode the soname in the developer
support package too. What's wrong with just PKG-dev-VER ? (libc5 is
a special case, because you also want to be able to have libc4-dev.)
> 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.
Right. When we've had the argument about the -dev package, I'll
summarise this for the Guidelines.
Ian.
Reply to: