[Nut-upsdev] Re: New automake targets and Debian packages

Peter Selinger selinger at mathstat.dal.ca
Sun Nov 19 22:26:16 CET 2006


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
> 




More information about the Nut-upsdev mailing list