Splitting up lib{xslt,xml2} packages

[Charles Wilson]

Elfyn McBratney wrote:

>>>My inted layout is
>>>
>>>  libxml2         the runtime library
>>>  libxml2-doc     manuals, docs, etc
>>>  libxml2-devel   headers and static libs
>>>  libxml2-python  python bindings
>>>  libxml2-perl    perl modules (XML::)
>>>
>>>  libxslt         ...
>>>  libxslt-doc     ...
>>>  libxslt-devel   ...
>>>  libxslt-python  ...
>>

> 
> I've done that. I'm going to do this tomorrow if no one disagrees, as all it
> takes is uploading new packages.

I don't agree.  (in mean, in principle, yes, but I don't think your 
proposed package naming/splitting is the right way to do it).

#1. **Usually** it's nice if libxxxx are the actual DLL- and linklib- 
containing package, and everything else goes into xxxx- packages.   Like 
libncursesX vs. ncurses:

libncursesX      : DLLs
libncurses-devel : static libs, headers, import libs
ncurses          : the rest
ncurses-demo     : extra apps

The exception is if the upstream package itself is called "libsomething" 
-- for instance, libiconv or libtool.

Now. I'm not familiar with xml/xslt -- are they distributed as "libxslt" 
upstream, or as "xslt"?

#2.  the two runtime library packages should be versioned.  e.g.

libxml2_N where N corresponds to the -N.dll version number (eg. 
cygbz2-1.dll is distributed in libbz2_1 package.)

Now, libxslt contains three DLLs with different DLL numbers.  There are 
two (three?) ways to handle this:

a) bundle all of the DLLs into one "DLL" package, using the version 
number that is the maximum of all of the DLLs within.  Eg.
   cygexslt-0.dll
   cygxslt-1.dll
   cygxsltbreakpoint-1.dll
MAX(0,1,1) == 1, so these should be in 'libxslt1' package (that is, 
libxslt1-1.0.30-2.tar.bz2)  You need an '_', though, when the "real" 
package name ends in a numeral (xml2, bzip2).

This is what I did with ncurses, etc (sans underscore, of course)

b) bundle and use the SUM of all of the version numbers.  I don't know 
of any existing package that does this -- and it could lead to setup 
ordering errors if you ever move to (c), below.

c) separate tarball for each DLL - this is what I did for libintl2 and 
libcharset1 (both from the same gettext source bundle).  Even if you 
split up the DLL packages, all of the -devel stuff can stay in a single 
-devel package.


#3) **Ordinarily**, -devel packages should NOT be versioned.  So, your 
suggestion of 'libxslt-devel' (as opposed to 'libxslt1-devel') is a good 
one.  There are exceptions to this rule; see libpng, libdb)
--------------

So, I suggest

libxml2_2       the runtime library
libxml2-doc     manuals, docs, etc
libxml2-devel   headers and static libs (incl. xml2-config)
libxml2-python  python bindings
libxml2-perl    perl modules (XML::)

libxslt1        all three runtime libraries
libxslt-doc     ...
libxslt-devel   ...
libxslt-python  ...

Now, this requires updating requires: lines on some setup.hints in other 
packages -- but TRUST ME, it's better to face the pain now than later.

--Chuck