This is the mail archive of the cygwin-apps@cygwin.com 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.

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



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