Comments on: I need your advice on how to package MySQL Toolkit as one file http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/ Stay curious! Fri, 10 May 2013 18:25:19 +0000 hourly 1 http://wordpress.org/?v=3.5.1 By: some guy http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-11046 some guy Tue, 05 Jun 2007 20:30:11 +0000 http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-11046 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);

]]>
By: TimH http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10809 TimH Mon, 04 Jun 2007 20:23:02 +0000 http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10809 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.

]]>
By: Francois Saint-Jacques http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10738 Francois Saint-Jacques Mon, 04 Jun 2007 12:50:39 +0000 http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10738 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.

]]>
By: Xaprb http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10730 Xaprb Mon, 04 Jun 2007 12:02:27 +0000 http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10730 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.

]]>
By: Mikko Rantalainen http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10705 Mikko Rantalainen Mon, 04 Jun 2007 07:16:02 +0000 http://www.xaprb.com/blog/2007/06/03/advice-on-packaging-mysql-toolkit/#comment-10705 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.

]]>