This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]