From: Stephen Frost (sfrost_at_snowman.net)
Date: Mon 27 Dec 2004 - 14:22:19 GMT
* Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de) wrote:
> herbert_at_13thfloor.at (Herbert Poetzl) writes:
> > | * A lot of programs don't have documentation. Add man pages in DocBook?
>
> Maintainership of the man-pages will be a problem; especially in
> the current stage where features might be added or removed very
> fast. Incorrect documentation is worse than missing one.
It'd be nice if the commits of such feature addition/deletion also
included the appropriate documentation changes... In addition, the
man-pages could have a note in them about the current flux or some such.
> > | * pkglibdir is /usr/lib/util-vserver instead of /var/lib/util-vserver
>
> ??? this is standard in autoconf packages.
I was wondering a bit about this myself.. The difference between
/usr/lib and /var/lib is pretty clear- is there stuff in util-vserver
that modifies things in the /usr/lib/util-vserver install? Or does
util-vserver normally install into /var/lib/util-vserver and that's the
complaint? I notice on my packaging of 0.30.195 it's in /usr/lib and I
don't see anything in there that looks like having it there is wrong..
> > | * /etc/vserver/util-vserver-vars
>
> Please do not install 'util-vserver-vars' into /etc. There is nothing
> which can be changed at runtime across the entire toolset (binaries have
> the values statically compiled in). The file is badly named and should
> be called 'util-vserver-consts' instead of.
I agree about the naming, and that it perhaps shouldn't even be packaged
at all (or installed by make install- is it?), but I'm a little
concerned about some of the constants that are in there- what's the
problem with searching the path for things like awk, grep, etc?
> > | * Both /usr/include/ and /usr/lib/pkgconfig/ are installed by
> > | default. What is include/vserver.h installed for?!
>
> Support for 3rd party language bindings were the main idea behind an
> libvserver library. Dunno, if there is much interest in such ones but I
> do not see reasons not to ship the -devel files.
Is the API/ABI adequately supported to really allow for people to be
able to develop against it and depend on it? I'm guessing 'no'
considering on 0.30.195 it looks like I've got a 'libvserver.so.0.0.0'.
If the API/ABI isn't handled correctly through soname and soversion
changes and whatnot then they should *not* be included in Debian. If
someone complains because they want to build something against them or
depend on them then util-vserver will *need* to have proper API/ABI
support. Personally, I hope that just doesn't happen anytime soon. :)
> > | * It would be very convenient if upstream could ship the graphviz
> > | output with the releases, such that building for Debian doesn't
> > | require graphviz.
>
> How is this handled in other Debian packages with 'doxygen' support? I
> would like to ship only the files which are really needed to build the
> package.
Good question, honestly I don't know the answer to this one, I've only
just started looking into doxygen myself. :)
> > | * The distclean target does also remove util-vserver.spec which is
> > | shipped in the release tarball.
>
> Where is the problem? The corresponding clean-rule is autogenerated
> by autoconf and the file can be recreated by './configure' resp.
> './config.status'.
Sounds like maybe it shouldn't be shipped in the release tarball then..
Debian packages are generally built along the lines of 'make clean,
generate Debian diff, configure, make, make install'. We don't like
things showing up in the Debian diff that shouldn't really be there. :)
It makes everyone's life harder having to deal w/ large diffs...
Stephen
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver