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