vserver development mailing list: Re: [Vserver] packaging review for new Debian packages

Re: [Vserver] packaging review for new Debian packages:
vserver development mailing list
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]

On Mon, Dec 27, 2004 at 04:26:45PM +0100, Kilian Krause wrote:
> Hi Enrico,
>
> > > | * /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 don't. There's no single rule which would put it there in my
> packaging. Thus this is coming from the install or install-distribution
> targets.
>
> If i did copy the specfile wrong, i'm sorry for that. That's why i'm
> asking what target is to be called.
>
> Yet the option to allow a relocation of the default vserver rootdir
> would be highly appreciated. (and IMHO broken if not availble at all)
>
> >
> > > | * util-vserver contains a large number of utilities - binaries and
> > > | shell scripts. These utilities serve different purposes and belong
> > > | to different conceptual layers.
> >
> > 'contrib/manifest.dat' contains the proposed grouping/subpackaging. See
> > the %install stage of the shipped .spec file for ways how to use it.
>
> Ok, will check that. Thanks.
>
> >
> > > | * 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.
>
> 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.

> > > | 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.
>
> I need: doxygen, tetex-bin, tetex-extras, gs, graphviz
> alltogether to build the "doc" target. And shipping only the "needed to
> build" sounds like a good idea as that IMHO involves a static doc
> already.

in general I think that documentation should be optional
so that somebody recompiling the stuff can easily do
that (with all the required tools installed) or leave
the doc package out, I'm personally annoyed by packages
insisting to build a documentation, when all I need is
a working binary (especially if they require huge addons
like gs or tetex)

> > > | * What is recommended for packaging, running both install and
> > > | install-distribution (along with make all doc) or just make install?
> >
> > The 'install-distribution' target installs files outside of $(prefix). These
> > are the /vservers directory and the /sbin/vshelper symlink.
> >
> >
> > > | * 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'.
>
> The point is you don't delete files you ship in the release tarball.
> Thus if the spec is included in the official tarball the clean shouldn't
> remove it.

> > > | * There is a number of compile warnings. Some of them sound
> > > | like they should be fixed. Are they ok as can be seen at:
> > > | http://backend.verfaction.de/~kk/util-vserver/buildlog_stderr.log
> >
> > The only true ones are the missing strchr()/strlen() declarations and
> > the unknown '\params' doxygen directive. First issue should be solved in
> > CVS some time ago, latter will be fixed soon.
> >
> > The other warnings are caused by incomplete and currently unused
> > code (vserver-start/*), support for the kernel 2.4 API and missing
> > documentation.
>
> Ok, sounds fine to me. =)
>
> > > | # remove newvserver.defaults (because that is linuxconf and that is not
> > > | supported in debian).
> > > | rm -f $(CURDIR)/debian/util-vserver/etc/vservers/newvserver.defaults
> >
> > this should not be installed by 'make install*'.
>
> ok, will check that.
>
> >
> > > | # New since SID for they are not standard for a Debian binary package
> > > | rm -rf $(CURDIR)/debian/util-vserver/usr/include/
> > > | rm -rf $(CURDIR)/debian/util-vserver/usr/lib/pkgconfig/
> >
> > I do not understand the reason behind this...
>
> 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)