This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: Splitting up lib{xslt,xml2} packages
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
--