Package naming convention and contents

[David Stacey]

On 12/07/13 09:35, Corinna Vinschen wrote:
> On Jul  8 20:06, David Stacey wrote:
>> >I am preparing a library package called Poco. Whilst Marco gave me a
>> >GTG, both he and Ken were a little unsure about the package names
>> >that I had used. Please could some of you good folk give me a little
>> >guidance in this matter.
>> >
>> >At the moment, I have tried to copy the naming convention used by
>> >our 'boost' package, as Poco is similar in its layout and intended
>> >usage. I have a source package (poco-1.4.6p1-1.src.tar.bz2) that
>> >builds the following:
>> >
>> >
>> >libpoco1.4.6
>> >   - Several versioned libraries, e.g. cygPocoData_1_4_6.dll.
>> >   - A couple of unversioned executables.
>> >
>> >libpoco-devel
>> >   - Header files and libs to link against Poco.
>> >
>> >libpoco-doc
>> >   - HTML documentation.
>> >
>> >poco-debuginfo
>> >   - Debug files, generated by cygport.
>> >
>> >
>> >The contentious package is the first one. The point of having
>> >versioned library files is that you can have any number of them
>> >installed side-by-side (if you'll forgive the Microsoftism). In that
>> >way, some other package will always pull in the exact version of
>> >Poco that it was linked against. For that reason, the two
>> >unversioned executables don't belong here, and I should probably
>> >move them into a package simply called 'poco'. However, unless
>> >there's an API breakage, versioned libraries shouldn't be necessary.
>> >
>> >Then there's the name of the package itself. This could have been
>> >'libpoco', 'libpoco1', or 'libpoco1.4'. The first of these is
>> >probably wrong, as there is some intention to release Poco 2.x at
>> >some point that will require a C++11 compliant compiler. Hence,
>> >we'll may want to support Poco 1.x for a while. Reading the change
>> >log, it appears that API changes can come in at any release.
> I had hoped somebody else would reply here since I'm a bit fuzzy on the
> library naming schemes.
>
> Basically versioning is good.  If the project uses libtool, you get a
> unique version number usually, see, for instance, the libncurses
> packages (libncurses7, libncurses8, libncurses9, libncurses10).  The
> name of the package reflects the version number of the DLL
> (cygncurses-7.dll, cygncurses-8.dll, cygncurses-9.dll, cygncurses-10.dll.
>
> If the package does not use libtool, you should ideally go with what the
> upstream maintainers go with.  How are the libraries versioned on Linux,
> for instance?
>
> I just installed the Fedora "poco-foundation" package, which contains
> only the shared lib, on Fedora 19.  F19 has poco 1.4.2 and the shared
> lib is called libPocoFoundation.so.11.  A look into the source package
> shows that the number is noted in a file called "libversion".  The build
> process seems to make sure that the shared library get that number, and,
> looking into the sources I can see this:
>
>    build/rules/global:  LIBVERSION := $(shell cat $(POCO_BASE)/libversion)
>    */Makefile:          target_version = $(LIBVERSION)
>    build/config/CYGWIN: SHAREDLIBEXT     = .$(target_version).dll
>
> Apart from a wrong assumption in the build/config/CYGWIN file in terms
> of strip(1), which is unrelated, I don't understand why your lib isn't
> called cygPocoFoundation.11.dll.  Naturally the libray package name
> would be libpoco11.  Or, following the Linux lead, the package name
> could be poco-foundation-11.

Thank you for your advice - that is really helpful. I'll look at this 
over the weekend and send another [ITP] when I'm happy that I've got 
properly named versioned libraries and that I haven't broken any 
functionality in the process!

BTW, regarding the library name: there's some Cygwin-specific code in 
build/rules/lib that resets the library name - it removes the version 
number! I've patched this away, and now I'm getting versioned libraries 
with similar names to what you described.

Thanks again,

Dave.