Splitting up lib{xslt,xml2} packages
Charles Wilson
cygwin@cwilson.fastmail.fm
Sat Jun 28 20:06:00 GMT 2003
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.
Okay.
>>#2. the two runtime library packages should be versioned. e.g.
>>
>
> That's because of the multiple versions, right? Like with pcre.
Yes.
>>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.
--Chuck
More information about the Cygwin-apps
mailing list