From: Stephen Frost (sfrost_at_snowman.net)
Date: Mon 27 Dec 2004 - 17:52:05 GMT
* Herbert Poetzl (herbert_at_13thfloor.at) wrote:
> On Mon, Dec 27, 2004 at 04:26:45PM +0100, Kilian Krause wrote:
> > Has so far only _one_ app been coded outside the util-vserver domain? If
> > not, i'd vote for leaving this out until someone complains.
> hmm, well, the thing here is that we _should_ try
> to get folks adding/modifying stuff or adapting tools
> to become context/vserver aware (for administration
> purpose) like find, du, df, ... to use 'the' library
> because it will be able to cope with the various
> interface versions from stable vserver 1.2x up to
> recent devel versions 1.9.x, not to mention the syscall
> number and invocation which is different on almost
> every arch ...
> I agree that the library might need some adaptations
> first and probably also requires a documented API to
> be usable for 3rd party stuff ...
> but I guess nobody will complain if it isn't there,
> they just will recode or copy/paste the code from
> existing tools and create fragile versions which will
> break on the first change ... nothing anybody wants.
I think the answer here is pretty simple- properly document the API and
monitor the ABI and do proper SONAME/SOVER changes and we'll be glad to
create -dev/-lib versions for other people to code against, even if no
one uses them at first. Until that's done I think it's a very bad idea
to include the headers since it would encourage people to code against
it, which would have many of the same problems as if they just copied &
pasted the code except that they'd have good cause to be upset with us
for shipping it.
> > If i'd leave in the include/vserver.h i'd need to make a libvserver-dev
> > package. Thus not shipping no header at all is the clean solution here.
> > And the pkgconfig isn't used on Debian, thus no need to ship it either.
> the library, plus (maybe sanitized) headers are a good
> candidate for a devel package, which IMHO is a reasonable
> thing to do (see comments above)
The library would be in a libvserver package if something outside of
util-vserver used it. Until it's got decent API documentation and a
real SONAME/SOVER that's actually monitored and updated when ABI changes
are made I'm strongly against having a libvserver/-dev package in
Vserver mailing list