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

Elfyn McBratney wrote:

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.

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).

and the other runtime package needs to be libxslt1 not libxslt.

However, by doing this, now you no longer have a "libxslt" or "libxml2" package available. Here's what I suggest:

create a dummy (empty) libxslt and libxml2 package, that require: their replacement. e.g. the dummy libxslt package requires: libxslt1, the dummy libxml2 package requires: libxml2_2

I guess the binaries (xmllint et al) should go
in -devel .

I dunno -- probably. I normally put user executables into the undecorated package (libxml2, libxslt, "ncurses"), but if they are really just development tools then they should go into the -devel.

However, if you decide to put them into the undecorated packages, then ignore the stuff about 'dummy packages' above. You'll still need to requires: <DLLpackage> though.

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..

No, I think alias flags would cause more trouble than they are worth. You'd end up with a corrupted setup.ini, but it would be extremely difficult to backtrack it through the aliases to figure out where the problem was and whodunnit.

But, it's a moot point right now, since we don't have aliases.


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