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

[Charles Lepple]

On 11/19/06, Peter Selinger <selinger at mathstat.dal.ca> wrote:
> The reason it's crude is because it takes a long time to re-run
> ./configure.

yikes.

> 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?

I'll check and see how this works in other packages. I think our
particular system is not that common, though, due to the way that
libusb-dependent and NetSNMP-dependent binaries are mixed in the same
directory with other binaries. There are definitely packages out there
that move stuff between directories based on wildcards (lib*.so*,
*.pc, etc), but again, I'm trying to avoid hardcoding a list of USB
drivers in the rules file.

Maybe a better way is to have subdirectories for serial, SNMP and USB
drivers, and the build system could just cd into the appropriate
directories for 'make install' instead of doing 'make install' from
the top level.

> 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
> >
>
>


-- 
- Charles Lepple