On Fri, 27 Jun 2003, Charles Wilson wrote: > 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"?
Yes, they're distributed as libxml2 and libxslt. > #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) That's because of the multiple versions, right? Like with pcre. > -------------- > > 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 ... That's pretty much the layout I'm using. I just need to change the name of the runtime package (to libxml2_2). I guess the binaries (xmllint et al) should go in -devel . > 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. Oh well, tomorrow's another awk'ing day. Wouldn't an 'alias' flags be helpful in setup.ini . Hmm.. > --Chuck Thanks, Chuck. Elfyn --