<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: We interrupt this travelogue for some actual Metacity questions</title>
	<atom:link href="http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/</link>
	<description>Thomas Thurman does not like cold meals because of broken applications.</description>
	<lastBuildDate>Fri, 30 Jul 2010 12:08:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Zack</title>
		<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/comment-page-1/#comment-324</link>
		<dc:creator>Zack</dc:creator>
		<pubDate>Mon, 06 Oct 2008 21:16:59 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/tthurman/?p=113#comment-324</guid>
		<description>ooh, good idea re making the filtering part of the build.

I realize I&#039;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.</description>
		<content:encoded><![CDATA[<p>ooh, good idea re making the filtering part of the build.</p>
<p>I realize I&#8217;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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan Nicholson</title>
		<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/comment-page-1/#comment-323</link>
		<dc:creator>Dan Nicholson</dc:creator>
		<pubDate>Mon, 06 Oct 2008 19:14:04 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/tthurman/?p=113#comment-323</guid>
		<description>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 &#039;s/foo/bar/&#039; $$@

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&#039;s the only sane course of action. This generally makes people upset.</description>
		<content:encoded><![CDATA[<p>For the autotools part, there are a couple alternatives.</p>
<p>1. You could just make the filtering part of the build. So you have something like:</p>
<p>bin_SCRIPTS = foo<br />
foo: foo.in<br />
    $(SED) -e &#8216;s/foo/bar/&#8217; $$@</p>
<p>Then the install takes care of itself.</p>
<p>2. Hack it with install-*-local or install-*-hook like Rob says. This requires that you handle appropriate cleanup, too.</p>
<p>3. Clean, but maybe too dependent on automake internals: redefine the specific install command.</p>
<p>binSCRIPT_INSTALL = $(builddir)/filter</p>
<p>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.</p>
<p>I would avoid the suggestion to have the Makefile be GNU make specific unless it&#8217;s the only sane course of action. This generally makes people upset.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Neary</title>
		<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/comment-page-1/#comment-322</link>
		<dc:creator>Dave Neary</dc:creator>
		<pubDate>Mon, 06 Oct 2008 12:07:12 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/tthurman/?p=113#comment-322</guid>
		<description>About the Nebraska &amp; Maine thing, it&#039;s actually a little more complicated than proportional... all but 2 electors are awarded on a majority basis per congressional district, with the two &quot;senate&quot; EVs being awarded to the winner of the state&#039;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 &amp; blue respectively.</description>
		<content:encoded><![CDATA[<p>About the Nebraska &amp; Maine thing, it&#8217;s actually a little more complicated than proportional&#8230; all but 2 electors are awarded on a majority basis per congressional district, with the two &#8220;senate&#8221; EVs being awarded to the winner of the state&#8217;s popular vote.</p>
<p>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 &amp; blue respectively.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Henstridge</title>
		<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/comment-page-1/#comment-321</link>
		<dc:creator>James Henstridge</dc:creator>
		<pubDate>Mon, 06 Oct 2008 12:06:59 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/tthurman/?p=113#comment-321</guid>
		<description>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&#039;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.</description>
		<content:encoded><![CDATA[<p>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.</p>
<p>As far as there being multiple binary packages for metacity in Ubuntu, I&#8217;d expect that they all come from the same source package (see <a href="https://launchpad.net/ubuntu/+source/metacity/1:2.24.0-0ubuntu1" rel="nofollow">https://launchpad.net/ubuntu/+source/metacity/1:2.24.0-0ubuntu1</a> for an example).  If you base your builds on the existing Ubuntu packaging, you should end up with the same set of binary packages.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James</title>
		<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/comment-page-1/#comment-320</link>
		<dc:creator>James</dc:creator>
		<pubDate>Mon, 06 Oct 2008 11:36:57 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/tthurman/?p=113#comment-320</guid>
		<description>The reason there are three packages is to save space - with 10+ architectures, even 2MB in metacity-common is 20MB saved on the mirrors.</description>
		<content:encoded><![CDATA[<p>The reason there are three packages is to save space &#8211; with 10+ architectures, even 2MB in metacity-common is 20MB saved on the mirrors.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Thomas Thurman</title>
		<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/comment-page-1/#comment-319</link>
		<dc:creator>Thomas Thurman</dc:creator>
		<pubDate>Mon, 06 Oct 2008 11:19:13 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/tthurman/?p=113#comment-319</guid>
		<description>@fatal:
I did actually try using &quot;Replaces&quot;, but it got eaten somewhere along the line between package creation and viewing it with apt-cache when it was in the PPA.  I&#039;ll read the policy more carefully, and play with lintian, and see what I missed.  Thanks.</description>
		<content:encoded><![CDATA[<p>@fatal:<br />
I did actually try using &#8220;Replaces&#8221;, but it got eaten somewhere along the line between package creation and viewing it with apt-cache when it was in the PPA.  I&#8217;ll read the policy more carefully, and play with lintian, and see what I missed.  Thanks.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: chpe</title>
		<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/comment-page-1/#comment-318</link>
		<dc:creator>chpe</dc:creator>
		<pubDate>Mon, 06 Oct 2008 09:37:59 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/tthurman/?p=113#comment-318</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: anonymous</title>
		<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/comment-page-1/#comment-317</link>
		<dc:creator>anonymous</dc:creator>
		<pubDate>Mon, 06 Oct 2008 09:16:04 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/tthurman/?p=113#comment-317</guid>
		<description>Yeah you just got hit by  the debian package naming crap. Whatever they are trying to solve the abstraction leaks all over the place.</description>
		<content:encoded><![CDATA[<p>Yeah you just got hit by  the debian package naming crap. Whatever they are trying to solve the abstraction leaks all over the place.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rob</title>
		<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/comment-page-1/#comment-316</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Mon, 06 Oct 2008 06:32:48 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/tthurman/?p=113#comment-316</guid>
		<description>Hi, 

below is some (untested) automake snippet that should do (if i understood your problem). Let me know if there&#039;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</description>
		<content:encoded><![CDATA[<p>Hi, </p>
<p>below is some (untested) automake snippet that should do (if i understood your problem). Let me know if there&#8217;s any problems.</p>
<p>*** </p>
<p>noinst_PROGRAMS = filter</p>
<p>filter_SOURCES = filter.c</p>
<p>filtee_place = $(datadir)/foo</p>
<p>install-data-local:<br />
	./filter  $(filtee_place)/filtee.txt</p>
<p>uninstall-local:<br />
	rm $(filtee_place)/filtee.txt</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: fatal</title>
		<link>http://blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/comment-page-1/#comment-315</link>
		<dc:creator>fatal</dc:creator>
		<pubDate>Mon, 06 Oct 2008 06:15:44 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.gnome.org/tthurman/?p=113#comment-315</guid>
		<description>Use Provides + Conflicts + Replaces .... see the debian policy further details about each.</description>
		<content:encoded><![CDATA[<p>Use Provides + Conflicts + Replaces &#8230;. see the debian policy further details about each.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- This Quick Cache file was built for (  blogs.gnome.org/tthurman/2008/10/06/i-like-trifle/feed/ ) in 1.17595 seconds, on Feb 12th, 2012 at 12:43 am UTC. -->
<!-- This Quick Cache file will automatically expire ( and be re-built automatically ) on Feb 12th, 2012 at 1:43 am UTC -->
