Nut upsdev - Nov 2006 - New automake targets and Debian packages

I was trying to merge the Debian unstable packaging files with the NUT
trunk, and I noticed a bit of a problem with the automake changes.

For the uninitiated, the 'debian/rules' file is essentially a Makefile
that is used to build the package and split things into the
sub-packages. If you look at line 85 of this copy of the rules file:

http://boxster.ghz.cc/projects/nut/browser/trunk/packaging/debian/rules#L85

you will notice that the old "install-*" targets are used to
distribute the files between the packages.

Basically, whatever is in debian/nut-usb after running through "rules"
will end up in the nut-usb-<version> package, etc. That means we coud
potentially use the new unified "install" target, and move files out
of debian/nut into debian/nut-{usb,snmp,dev,cgi} afterwards.

However, if we do that, we are ignoring the information in Makefile.am
about which subsystem a given file belongs to. If I read things
correctly, the "--with-XYZ" options still need programs to be grouped
so that they can be enabled or disabled at config time. The problem is
that we would like to configure just once, build just once (so we do
not need all the old "build-*" targets) and install multiple times
with different $DESTDIR settings.

Peter: how hard would it be to bring back the install-* targets? If
you're busy, I can crack open my Automake book and look at this, but
I'm sure there was a reason for doing it the way you did, even if it
was just to simplify the conversion. I was a little confused at some
of the variable names, but that's probably because I was trying to
compare it with the old build system.

Arnaud: do you have a suggestion for how we could handle this better?
Again, I don't want to have too much information repeated in the
packaging directory, since things can easily get out of sync later on.
Also, what is the "RUNUID" stuff for? Won't that get ignored if I
use
"fakeroot" to build the debs? Don't worry, I won't commit any
changes
to debian/ in the top-level directory; it'll go in packaging/debian
like before.

-- 
- Charles Lepple

Hi Charles,

I see the problem you describe. I first thought of the following
solution:

./configure --with-cgipath=debian/whatever-cgi

but this will not work, because the --with-cgi option not only
installs binaries, but also man pages etc., and there is no separate
cgimanpath (and it would be a bit crazy to create one). 

There's a somewhat crude workaround to "extract", say, only the
USB
related install files:

./configure --with-usb 
make DESTDIR=/somewhere install
./configure --without-usb 
make DESTDIR=/somewhere uninstall

This will leave just the USB-related files under /somewhere. 
The reason it's crude is because it takes a long time to re-run
./configure. 

The problem with install-* targets is that they are not supported by
automake unless you essentially write the targets "by hand". This is
not usually portable. For example, before installing, you need to
create the installation directory if it does not already exist. On
most platforms, "mkdir -p" does this, but alas, on some platforms this
does not work. Automake knows about such situations and implements it
in a portable way.

I assume that the other 99999 Debian packages use Automake, so perhaps
we should see if they have a standard way of splitting the package? It
would seem that they had to hack the "rules" file precisely because
NUT was using a non-standard build system. It seems reasonable to
assume that they already know how to split other packages, and that
they have some standard support for this. 

-- Peter



Charles Lepple wrote:
> 
> I was trying to merge the Debian unstable packaging files with the NUT
> trunk, and I noticed a bit of a problem with the automake changes.
> 
> For the uninitiated, the 'debian/rules' file is essentially a
Makefile
> that is used to build the package and split things into the
> sub-packages. If you look at line 85 of this copy of the rules file:
> 
> http://boxster.ghz.cc/projects/nut/browser/trunk/packaging/debian/rules#L85
> 
> you will notice that the old "install-*" targets are used to
> distribute the files between the packages.
> 
> Basically, whatever is in debian/nut-usb after running through
"rules"
> will end up in the nut-usb-<version> package, etc. That means we coud
> potentially use the new unified "install" target, and move files
out
> of debian/nut into debian/nut-{usb,snmp,dev,cgi} afterwards.
> 
> However, if we do that, we are ignoring the information in Makefile.am
> about which subsystem a given file belongs to. If I read things
> correctly, the "--with-XYZ" options still need programs to be
grouped
> so that they can be enabled or disabled at config time. The problem is
> that we would like to configure just once, build just once (so we do
> not need all the old "build-*" targets) and install multiple
times
> with different $DESTDIR settings.
> 
> Peter: how hard would it be to bring back the install-* targets? If
> you're busy, I can crack open my Automake book and look at this, but
> I'm sure there was a reason for doing it the way you did, even if it
> was just to simplify the conversion. I was a little confused at some
> of the variable names, but that's probably because I was trying to
> compare it with the old build system.
> 
> Arnaud: do you have a suggestion for how we could handle this better?
> Again, I don't want to have too much information repeated in the
> packaging directory, since things can easily get out of sync later on.
> Also, what is the "RUNUID" stuff for? Won't that get ignored
if I use
> "fakeroot" to build the debs? Don't worry, I won't commit
any changes
> to debian/ in the top-level directory; it'll go in packaging/debian
> like before.
> 
> -- 
> - Charles Lepple
>

fellows,

sorry not to have answered before...

2006/11/19, Charles Lepple <clepple@gmail.com>:
> I was trying to merge the Debian unstable packaging files with the NUT
> trunk, and I noticed a bit of a problem with the automake changes.
thanks a lot Charles for this much appreciated help on this point ;-)
> For the uninitiated, the 'debian/rules' file is essentially a
Makefile
> that is used to build the package and split things into the
> sub-packages. If you look at line 85 of this copy of the rules file:
>
> http://boxster.ghz.cc/projects/nut/browser/trunk/packaging/debian/rules#L85
>
> you will notice that the old "install-*" targets are used to
> distribute the files between the packages.
>
> Basically, whatever is in debian/nut-usb after running through
"rules"
> will end up in the nut-usb-<version> package, etc. That means we coud
> potentially use the new unified "install" target, and move files
out
> of debian/nut into debian/nut-{usb,snmp,dev,cgi} afterwards.
>
> However, if we do that, we are ignoring the information in Makefile.am
> about which subsystem a given file belongs to. If I read things
> correctly, the "--with-XYZ" options still need programs to be
grouped
> so that they can be enabled or disabled at config time. The problem is
> that we would like to configure just once, build just once (so we do
> not need all the old "build-*" targets) and install multiple
times
> with different $DESTDIR settings.
>
> Peter: how hard would it be to bring back the install-* targets? If
> you're busy, I can crack open my Automake book and look at this, but
> I'm sure there was a reason for doing it the way you did, even if it
> was just to simplify the conversion. I was a little confused at some
> of the variable names, but that's probably because I was trying to
> compare it with the old build system.
>
> Arnaud: do you have a suggestion for how we could handle this better?
> Again, I don't want to have too much information repeated in the
> packaging directory, since things can easily get out of sync later on.
> Also, what is the "RUNUID" stuff for? Won't that get ignored
if I use
> "fakeroot" to build the debs? Don't worry, I won't commit
any changes
> to debian/ in the top-level directory; it'll go in packaging/debian
> like before.
no worry, this doesn't harm until an official upload ;-)
so you can safely commit it to the trunk.
Note that, part of the 2.2 switch, I want to merge the nut and nut-usb
packages, so the split gives:
nut (provides nut-usb, and also nut-doc until 2.4)
nut-dev
nut-cgi
nut-snmp

So the install rules are limited to the development files, and CGI /
SNMP things (note that I haven't yet gone through the automake and
install thread...).

Also note that I've "validated" 2 NMUs (Non Maintainer Uploads)
dealing with the udev rules, so you can also merge these...

thanks again,
Arnaud
-- 
Linux / Unix Expert - MGE UPS SYSTEMS - R&D Dpt
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://people.debian.org/~aquette/
OpenSource Developer - http://arnaud.quette.free.fr/