There are two things I’d like some help with in Metacity at the moment. Perhaps someone here can throw me a clue.
- Is it easy in autotools, during the install step, instead of copying one of the binaries you just built anywhere, to filter one of the other files you’re about to install through it? This would be the only use of this binary. Is this going to require writing copious m4?
- I was asked to provide nightly binaries in Launchpad PPA for Metacity. My .deb packaging skills are fairly basic; here is what I’ve made, but it doesn’t work. The problem is that Metacity exists in about three different packages in Ubuntu. Either the nightly could have a new package name like “metacity-nightly-trunk”, and use some kind of control line to replace the other packages (but what?), or (as I’m currently trying) it could have the same name as one of the existing packages. But that doesn’t work, because it would want to replace files from the other packages too, unless we split it into three packages, and that would be problematic because I want to keep it as close to a fresh install from trunk as possible. Which of these is a better idea, and how can I overcome the problems with each? The script which created these is here; I hope to run it from a cronjob.
Unrelatedly, here is something worth knowing:
Nebraska and Maine are the only two states
Where electors divide in proportional rates,
Where more get the great share, and fewer the small;
The forty-eight others are winner-takes-all.
Re the first question, I think you don’t have to write any m4 at all, only Makefile rules. Are you using automake? If so, you should consider replacing it with a hand-written gmake-specific makefile, as it will be much less hassle in the long run, but until then, I think what you do is use noinst_bin_PROGRAMS= instead of bin_PROGRAMS= for the only-run-during-installation binary, and then you write an install-local rule to do what you want with it. I don’t know how you make that cross-compile safe, though. That’s one of the ways it’s less hassle in the long run not to use automake.
Use Provides + Conflicts + Replaces …. see the debian policy further details about each.
Hi,
below is some (untested) automake snippet that should do (if i understood your problem). Let me know if there’s any problems.
***
noinst_PROGRAMS = filter
filter_SOURCES = filter.c
filtee_place = $(datadir)/foo
install-data-local:
./filter $(filtee_place)/filtee.txt
uninstall-local:
rm $(filtee_place)/filtee.txt
Yeah you just got hit by the debian package naming crap. Whatever they are trying to solve the abstraction leaks all over the place.
I guess you could just do it completely in Makefile.am, using noinst_PROGRAMS for the filter and an install-data-local rule that filters the file to a tempfile and then uses $(INSTALL_DATA) to install that.
@fatal:
I did actually try using “Replaces”, but it got eaten somewhere along the line between package creation and viewing it with apt-cache when it was in the PPA. I’ll read the policy more carefully, and play with lintian, and see what I missed. Thanks.
The reason there are three packages is to save space – with 10+ architectures, even 2MB in metacity-common is 20MB saved on the mirrors.
You probably want to maintain the same package name as the official ones, but use a version number like $LAST_RELEASED_VERSION+svn$REVISION-something, so that it appears newer than what you previously released but older than future releases.
As far as there being multiple binary packages for metacity in Ubuntu, I’d expect that they all come from the same source package (see https://launchpad.net/ubuntu/+source/metacity/1:2.24.0-0ubuntu1 for an example). If you base your builds on the existing Ubuntu packaging, you should end up with the same set of binary packages.
About the Nebraska & Maine thing, it’s actually a little more complicated than proportional… all but 2 electors are awarded on a majority basis per congressional district, with the two “senate” EVs being awarded to the winner of the state’s popular vote.
So in Nebraska, for example, there is one EV available in the congressional district around Omaha, where Obama has a fighting chance, and in Maine, there is one district where McCain has a small chance of pinching it, but both states will be heavily red & blue respectively.
For the autotools part, there are a couple alternatives.
1. You could just make the filtering part of the build. So you have something like:
bin_SCRIPTS = foo
foo: foo.in
$(SED) -e ‘s/foo/bar/’ $$@
Then the install takes care of itself.
2. Hack it with install-*-local or install-*-hook like Rob says. This requires that you handle appropriate cleanup, too.
3. Clean, but maybe too dependent on automake internals: redefine the specific install command.
binSCRIPT_INSTALL = $(builddir)/filter
Where filter takes the input and output files as $1 and $2. If you look at a generated Makefile, you will see that this variable (or binPROGRAMS_INSTALL in the case of programs) is set to $(INSTALL_SCRIPT) by default. I suppose you could just redefine INSTALL_SCRIPT, but that would apply to the whole Makefile.
I would avoid the suggestion to have the Makefile be GNU make specific unless it’s the only sane course of action. This generally makes people upset.
ooh, good idea re making the filtering part of the build.
I realize I’m the lone voice in the wilderness with advocating use of handwritten, gmake-specific makefiles over automake. However, I am convinced the world would be a better place if everyone stopped using automake; the only practical way to do that is if everyone can instead expect to have access to a more powerful make implementation than the POSIX least common denominator; and GNU make is the obvious choice.