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