Hi, I must admit I did not make change to the way the init.d is installed so if it was not working in the 1.3.8-0pre2 packages already posted in the wiki it most probably still does not work. When talking about seperating the binary packages, I suppose you are talking about seperating -client and -server packages? Since there is now only one binary shipped (glusterfs) that acts both as client and server, I don't see the point of splitting the packages... Your other points regarding depending on lsb-base, using debhelper scripts and fixing the init.d seems all very valid and if you know how to fix all these problems it would be great if you did.. I made my source package for 1.3.9 available at: http://smashweb.com/glusterfs/ Improvements welcome. Regards, Cedric Le dimanche 01 juin 2008 à 18:56 -0300, Andre Felipe Machado a écrit : > Hello, > IMHO, the packaging needs a bit more minor improvements before > uploading. The init.d is not being installed correctly with 1.3.9. (I > did not evaluate Mr. Cedric's patch yet. Could it be sent to my > address?). Beyond the trivial file name issue, it is not installing the > init.d script completely and correctly at a Debian machine the "debian > way", leveraging the debhelper tools for these tasks. Also, as a > suggestion, the samples placed at /etc/glusterfs/ could be renamed > (worse alternative) or the init.d script modified for using the > CONFIGFILE parameter for the same name without ".sample" (better > alternative), leaving the file names as they are. The user will know > that editing file and simply removing the ".sample" suffix will work. > It is even possible to place them as "final" names, without ".sample" , > configuring only for localhost, and using debhelper for configuration > files. > This way, if user modifies the files (and he/she should), > the debconf will know that and offer to preserve/merge/substitute them. > Or these sample files moved to /etc/default (using only localhost) and > init script adapted for using them. > > Also, the init script uses functions of lsb-base, and the debian > control file does not list it as a dependency. The init.d glusterfsd > script uses double commands, for RH and for Debian, I guess. A correct > implementation of LSB init scripts could use different options and a > simpler script. The Debian start-stop-daemon is using "--startas" > option. Could this option allow duplicated instances of the daemon (if > the previous test status is removed)? The "--exec" options checks if a > previous instance is running and exits with error, or when used with > "--oknodo" ignores it and starts another instance, like "--startas". > Is it correct? If so, is it the intended behaviour for glusterfsd? > > The rules file is almost not using the debhelper scripts, that could > make things easier for packagers. > > There are some hints, and extensive bibliography (External useful > links), > that could help at the page: > How to split a package into several smaller packages - How to create > multiple binaries packages from one source package. [0] > > I hope these help. > Regards. > Andre Felipe Machado > http://www.techforce.com.br > > > [0] http://wiki.debian.org/PkgSplit > > > > > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel
