<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.2.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: I need your advice on how to package MySQL Toolkit as one file</title>
	<link>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/</link>
	<description>Stay curious!</description>
	<pubDate>Sun, 20 Jul 2008 11:27:42 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.2.2</generator>

	<item>
		<title>By: some guy</title>
		<link>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-11046</link>
		<author>some guy</author>
		<pubDate>Tue, 05 Jun 2007 20:30:11 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-11046</guid>
		<description>For such a collection of rather small programs I would stick with one subversion tree and maybe use SVN keywords as program specific versions:

#include "version.h"
printf("mysql-foo revision %d from mysql-tools %s",
  $LastChangedRevision$,
  package_version_from_version_dot_h);</description>
		<content:encoded><![CDATA[<p>For such a collection of rather small programs I would stick with one subversion tree and maybe use SVN keywords as program specific versions:</p>
<p>#include &#8220;version.h&#8221;<br />
printf(&#8221;mysql-foo revision %d from mysql-tools %s&#8221;,<br />
  $LastChangedRevision$,<br />
  package_version_from_version_dot_h);</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TimH</title>
		<link>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10809</link>
		<author>TimH</author>
		<pubDate>Mon, 04 Jun 2007 20:23:02 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10809</guid>
		<description>i like the idea of /tags/latest
that would simplify your compiling your latest package instead of recursing all dirs to find the latest of each. also, i would vote for /tags/software-name/software-name-v.v.v  INSTEAD of /tags/v.v.v/software-name-v.v.v. Because Mikko stated, those are more related then the version numbers.  

Then, for each version of a single app, you would have to tag it twice, tag the real version number, tags/software-name/software-name-v.v.v and tags/latest/software-name-v.v.v.

Also, i would vote for a single version release number for each package accross each individual apps. For the end-user, i think it makes more sense. Joe blow doesnt care about all these different version numbers, he just want to make sure he has the latest package... although  Svens idea is good too, use the svn rev version for the package version.

for example, swftools package for linux, they use a single version number for each little app in there. this makes it simpler in the forums when i say, hey what version do you have, i dont have to translate -- "ok version 0.9.0 app = 1.5 package", i just install the 1.6 package when someone tells me i need the 1.6 app version.</description>
		<content:encoded><![CDATA[<p>i like the idea of /tags/latest<br />
that would simplify your compiling your latest package instead of recursing all dirs to find the latest of each. also, i would vote for /tags/software-name/software-name-v.v.v  INSTEAD of /tags/v.v.v/software-name-v.v.v. Because Mikko stated, those are more related then the version numbers.  </p>
<p>Then, for each version of a single app, you would have to tag it twice, tag the real version number, tags/software-name/software-name-v.v.v and tags/latest/software-name-v.v.v.</p>
<p>Also, i would vote for a single version release number for each package accross each individual apps. For the end-user, i think it makes more sense. Joe blow doesnt care about all these different version numbers, he just want to make sure he has the latest package&#8230; although  Svens idea is good too, use the svn rev version for the package version.</p>
<p>for example, swftools package for linux, they use a single version number for each little app in there. this makes it simpler in the forums when i say, hey what version do you have, i dont have to translate &#8212; &#8220;ok version 0.9.0 app = 1.5 package&#8221;, i just install the 1.6 package when someone tells me i need the 1.6 app version.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Francois Saint-Jacques</title>
		<link>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10738</link>
		<author>Francois Saint-Jacques</author>
		<pubDate>Mon, 04 Jun 2007 12:50:39 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10738</guid>
		<description>Make sure you have a "./configure" in order to change the prefix and *dir values. This will help porters to packages you software and respect file system structure.</description>
		<content:encoded><![CDATA[<p>Make sure you have a &#8220;./configure&#8221; in order to change the prefix and *dir values. This will help porters to packages you software and respect file system structure.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Xaprb</title>
		<link>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10730</link>
		<author>Xaprb</author>
		<pubDate>Mon, 04 Jun 2007 12:02:27 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10730</guid>
		<description>Sven: yes, RPM should be on the list too.  I guess I will need some people to help with it, because as I understand each RPM-based distro varies widely, so I would need several different RPMs.

Mikko: you mentioned one of the reasons I'm unhappy with the current tagging scheme.  Thanks for your suggestions.

I didn't mention this, but one of the Debian developers expressed interest in making some of the tools part of the mysql-client package.  Perhaps just as a dependency, I'm not sure.  I'll send an email that direction so I can get their suggestions/preferences too.</description>
		<content:encoded><![CDATA[<p>Sven: yes, RPM should be on the list too.  I guess I will need some people to help with it, because as I understand each RPM-based distro varies widely, so I would need several different RPMs.</p>
<p>Mikko: you mentioned one of the reasons I&#8217;m unhappy with the current tagging scheme.  Thanks for your suggestions.</p>
<p>I didn&#8217;t mention this, but one of the Debian developers expressed interest in making some of the tools part of the mysql-client package.  Perhaps just as a dependency, I&#8217;m not sure.  I&#8217;ll send an email that direction so I can get their suggestions/preferences too.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mikko Rantalainen</title>
		<link>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10705</link>
		<author>Mikko Rantalainen</author>
		<pubDate>Mon, 04 Jun 2007 07:16:02 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10705</guid>
		<description>I too think that RPM and .deb (for ubuntu/debian) would be nice. If at all possible, create a new repository for your .deb packages so that the upgrade process can be easily automated. (End user just adds your repository, installs you package once and any new versions or fixed you release will be automatically installed when the user updates his system next time).

I'd suggest using tags such as /tags/mysql-table-sync-0.8.0 instead because that's more like I've seen used by the other open source projects. Your current scheme looks odd because 0.9.0 contains releases of different tools from different times, just because different tools hit 0.9.0 in different times. They are not related except by identical version number string so they should not share a directory in my opinion. It would be nice if you had file /tags/LATEST which has the name of latest tag for each tool, one name per line. It could be automatically generated, though.

I'm not sure how it works for RPM but for .deb you can provide a virtual package named mysqltoolkit which contains no files but has dependencies set to latest release of each tool. That way end user can just add your repository to his /etc/apt/sources.lst and run aptitude install mysqltoolkit and have all the tools installed automatically (as dependencies). Also, he can decide to install just one tool instead by not installing the virtual package mysqltoolkit but instead just mysqltoolkit-mysql-table-sync, for example. Again, this all integrates nicely to the whole system and Ubuntu's update manager will then automatically upgrade to newer releases as they come available.</description>
		<content:encoded><![CDATA[<p>I too think that RPM and .deb (for ubuntu/debian) would be nice. If at all possible, create a new repository for your .deb packages so that the upgrade process can be easily automated. (End user just adds your repository, installs you package once and any new versions or fixed you release will be automatically installed when the user updates his system next time).</p>
<p>I&#8217;d suggest using tags such as /tags/mysql-table-sync-0.8.0 instead because that&#8217;s more like I&#8217;ve seen used by the other open source projects. Your current scheme looks odd because 0.9.0 contains releases of different tools from different times, just because different tools hit 0.9.0 in different times. They are not related except by identical version number string so they should not share a directory in my opinion. It would be nice if you had file /tags/LATEST which has the name of latest tag for each tool, one name per line. It could be automatically generated, though.</p>
<p>I&#8217;m not sure how it works for RPM but for .deb you can provide a virtual package named mysqltoolkit which contains no files but has dependencies set to latest release of each tool. That way end user can just add your repository to his /etc/apt/sources.lst and run aptitude install mysqltoolkit and have all the tools installed automatically (as dependencies). Also, he can decide to install just one tool instead by not installing the virtual package mysqltoolkit but instead just mysqltoolkit-mysql-table-sync, for example. Again, this all integrates nicely to the whole system and Ubuntu&#8217;s update manager will then automatically upgrade to newer releases as they come available.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sven Edge</title>
		<link>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10657</link>
		<author>Sven Edge</author>
		<pubDate>Mon, 04 Jun 2007 01:00:39 +0000</pubDate>
		<guid>http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10657</guid>
		<description>I'd love to have all these tools as one package, even an rpm perhaps. I  discovered the checksum tool a few months back and it was a real lifesaver. :)

As for versioning, you could version the apps separately, but just call the combined package version the svn rev it came from, eg r1234, and still refer to app versions in the changelog.</description>
		<content:encoded><![CDATA[<p>I&#8217;d love to have all these tools as one package, even an rpm perhaps. I  discovered the checksum tool a few months back and it was a real lifesaver. :)</p>
<p>As for versioning, you could version the apps separately, but just call the combined package version the svn rev it came from, eg r1234, and still refer to app versions in the changelog.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
