Re: Easiest way to Debianise a package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Apr 13, 2008 at 12:44 AM, Simon Ruggier wrote: If you're upstream, then for the sake of packagers, you probably want to release the data and source code in the same tarball, unless you like to release updates for them independently (i.e. if the source gets updated much more often than the data). That probably means I should include all the data files in the EXTRA_DIST variable in Makefile.am, right? This is confusing, but if I understand your question, then my answer is no. You only want the diff to include Debian specific changes, not upstream changes. In most cases the debian directory and the files within should be the only thing in the diff, but in the rare case that you need something changed for the clean target to work properly, then you might patch that in the diff as well. Thanks, you understood it, and that explains it :) - -- Ivan Vučica - -- Croatia -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFIAjndsunNof3e6g8RAvYdAJoDNhnkPEjp+FEVW9za7sBK0/0BgwCdH7VX mK0AcTfkPQhf13m9328z828= =R77A -END PGP SIGNATURE-
Re: Easiest way to Debianise a package?
* Ivan Vucica [EMAIL PROTECTED] [080413 19:09]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Apr 13, 2008 at 12:44 AM, Simon Ruggier wrote: If you're upstream, then for the sake of packagers, you probably want to release the data and source code in the same tarball, unless you like to release updates for them independently (i.e. if the source gets updated much more often than the data). That probably means I should include all the data files in the EXTRA_DIST variable in Makefile.am, right? As you want the data to end up somewhere, a dirname_data = might almost be a better idea, so that people using the source and installing per make install also get a fully working setup Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
On Fri, Apr 11, 2008 at 06:00:41PM +0200, Ivan Vucica wrote: 1. What are your recommendations with regards to what to use to perform initial debianisation of the project? Meaning - what should I use? Just debhelper? CDBS? I'd use dh-make, but I'm obviously biased in that regard. I didn't like CDBS myself. 2. Should data files be produced by same debianisation directory (by which I mean folder containing files copyright, rules, etc)? Depending on the relative sizes, data files should probably go in their own package. copyright goes into ALL Debian binary packages. rules files are required by all Debian source packages. 3. Should source file generated by autotools contain the data files? Will that make debianisation any easier? Generally make dist will create the Makefile.in and configure files but not the Makefile itself. Whatever make dist does should be good enough. 4. In case my questions are wrong: What would be your steps for producing packages project and project-data, considering what I mentioned above and directory structure below? I'd have a debian/project-data.files file and use dh_movefiles What would be your desires for upstream -- what should upstream do to make your life easier? Use autotools correctly (difficult and I'm usually the upstream!) Don't put undistributable files in the source package. Don't muck up the copyrights of various files, for example a mixture of files with conflicting copyrights. Don't mandatorily link to something not in Debian and that could not ever be in Debian. The autotools usually take care of it, but make sure its easy to shift the destination of the install target. For example you don't want make install to install something in /bin with no way of changing it with either a PREFIX or DESTDIR option. What would you do after fetching SVN (not tar.gz) that contains data as below, and whose make dist would generate .tar.gz containing just sources? There are some tools to make things easier, I'd just download the svn and make dist. - Craig -- Craig Small GnuPG:1C1B D893 1418 2AF4 45EE 95CB C76C E5AC 12CA DFA5 http://www.enc.com.au/ csmall at : enc.com.au http://www.debian.org/ Debian GNU/Linux, software should be Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I just want to say I'm glad that so many people have responded. I've read all the text, and you have indeed helped me in the right direction for further research. I don't have the time to further research at this point, so I'm mostly acknowledging your messages. I'd like to especially thank Siegfried-Angel for taking a very close look at YATC packaging, that means much to me since I intended to submit it to Debian. Of course, only in case project ever gets into state where it doesn't depend so much upon proprietary data and that it's playable. However some things in life are blocking me from furthering the project in that direction, but oh well. I'm glad someone with experience with Debian packaging and with Debian policies (latter being even more important than the first, in my opinion) has taken time to review the packaging in detail even though we didn't submit for uploading and sponsorship :) Thanks again, Siegfried! Also in response to Craig Small's message, I'd just like to write that your response is helpful, but I tried to structure my questions around my primary concern -- proper packaging of data files. So, I'll add a question: Does the original .tar.gz, produced by make dist, have to contain the data files? Or can I just copy them into destination directory afterwards so they get included into the .diff only (probably a bad idea)? And another one: YATC's .deb building process, as stated above, was pretty much automatized as outlined in README.Debian in SVN. (Didn't know what Debian-specific things to write there, so I wrote how to build .deb files; if it were a production ready package, I'd probably have smarter things to put there, but oh well.) What I basically do is this: * make dist * rm -rf debtmp * mkdir debtmp * cp yatc-0.2.tar.gz debtmp # some folder renaming here to produce yatc-0.2.20080412 -- that is, date based stuff appended for revision tracking * tar xvvfz yatc-0.2.tar.gz # thought about it and it's a bad idea since tar.gz does not contain folder renamed that way * cd yatc-0.2 * ./autogen.sh * ./configure [prefix options] * dpkg-buildpackage -rfakeroot As you can see I clean up the destination directory, debtmp, every time. Is that a good thing to do? Should I keep it, including the - -orig.tar.gz, to make it just keep a diff between one original SVN revision? (That is -- if I update the source from upstream, should I keep the build directory so that it produces the diff from an older tarball?) Or should I keep it only when changing between Debian revisions? (Meaning e.g. 0.2.20080412-1 = 0.2.20080412-2?) Should I keep it at all or is it safe to do a full rebuild every time? (It's probably frowned upon, but is it ok?) - -- Ivan Vučica - -- Croatia -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFIANcVsunNof3e6g8RAgzmAJ9tw85fM9LEMQ9+hjb4ei0O7vWElACgrOz3 R3Pmp7GUoy1NF2ItNsVssgs= =kGfj -END PGP SIGNATURE-
Re: Easiest way to Debianise a package?
On 4/12/08, Ivan Vucica [EMAIL PROTECTED] wrote: Does the original .tar.gz, produced by make dist, have to contain the data files? Or can I just copy them into destination directory afterwards so they get included into the .diff only (probably a bad idea)? They need to either be in the same orig.tar.gz as the source, or a different orig.tar.gz - if upstream doesn't release the data files along with the source, it's just a pain for the packager, since they have to make a orig.tar.gz file for the purpose of packaging the data. If the data and source are all in the same orig.tar.gz, you use a debian/foo.install file to list what goes in the architecture dependent package, and then a debian/foo-data.install file to list all the (architecture independent) data files. You split up the files into two packages because the data package can be reused for all of the architectures, since there's no machine code in it, which saves space. If you're upstream, then for the sake of packagers, you probably want to release the data and source code in the same tarball, unless you like to release updates for them independently (i.e. if the source gets updated much more often than the data). And another one: YATC's .deb building process, as stated above, was pretty much automatized as outlined in README.Debian in SVN. (Didn't know what Debian-specific things to write there, so I wrote how to build .deb files; if it were a production ready package, I'd probably have smarter things to put there, but oh well.) What I basically do is this: * make dist * rm -rf debtmp * mkdir debtmp * cp yatc-0.2.tar.gz debtmp # some folder renaming here to produce yatc-0.2.20080412 -- that is, date based stuff appended for revision tracking * tar xvvfz yatc-0.2.tar.gz # thought about it and it's a bad idea since tar.gz does not contain folder renamed that way * cd yatc-0.2 * ./autogen.sh * ./configure [prefix options] * dpkg-buildpackage -rfakeroot As you can see I clean up the destination directory, debtmp, every time. Is that a good thing to do? Should I keep it, including the - -orig.tar.gz, to make it just keep a diff between one original SVN revision? (That is -- if I update the source from upstream, should I keep the build directory so that it produces the diff from an older tarball?) Or should I keep it only when changing between Debian revisions? (Meaning e.g. 0.2.20080412-1 = 0.2.20080412-2?) Should I keep it at all or is it safe to do a full rebuild every time? (It's probably frowned upon, but is it ok?) This is confusing, but if I understand your question, then my answer is no. You only want the diff to include Debian specific changes, not upstream changes. In most cases the debian directory and the files within should be the only thing in the diff, but in the rare case that you need something changed for the clean target to work properly, then you might patch that in the diff as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Easiest way to Debianise a package?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Cheers, Since I have last bothered debian-devel-games, I have studied how to create packages. I was asking how to properly create executable packages separate from packages containing data files. This was for an MMORPG open source client replacement called YATC. I have produced something working somewhere in February; resulting Debian-producing files can be found int: * http://opentibia.svn.sf.net/svnroot/opentibia/yatc/trunk/debian/ * http://opentibia.svn.sf.net/svnroot/opentibia/yatc/trunk/debian-data/ This works and seems to produce somewhat valid packages -- it's installable, it works, and while I didn't check in detail with lintian and linda, it looks to me like it might pass for valid Debian packages. But the solution itself does not make me happy. I'm looking for a smarter way to produce Debian packages for future games, out of SVN'ed, autotools-using projects. I'm looking for information for cases where I am the upstream. That means I could use tips with proper use of autotools to make generating DEBs easier; I'm still generally struggling with autotools. My question is generic and not related to YATC. (For example, YATC's sources can't include data files since data files from original client are, well, not licensed for such distribution.) So, I have an autotools project. Punching in make dist produces project-0.1.tar.gz. make distcheck also produces a valid executable provided that all libraries are installed. Data files are not (currently) mentioned anywhere in the autotools data files such as Makefile.am, configure.ac, etc. Questions: 1. What are your recommendations with regards to what to use to perform initial debianisation of the project? Meaning - what should I use? Just debhelper? CDBS? 2. Should data files be produced by same debianisation directory (by which I mean folder containing files copyright, rules, etc)? 3. Should source file generated by autotools contain the data files? Will that make debianisation any easier? 4. In case my questions are wrong: What would be your steps for producing packages project and project-data, considering what I mentioned above and directory structure below? What would be your desires for upstream -- what should upstream do to make your life easier? What would you do after fetching SVN (not tar.gz) that contains data as below, and whose make dist would generate .tar.gz containing just sources? I would be most grateful if someone would bother and make one little Debinoob a little more one three three seven. P.S. I'm also not sure if my signing process is valid, so if someone could check if it signs the text correctly compared to the key published on URL below, I'd be grateful. (I'm trying to use FireGPG, Iceweasel extension to add few buttons to Gmail) http://ivucica.googlepages.com/ Example directory structure: aclocal.m4 AUTHORS autogen.sh autom4te.cache BUGS ChangeLog config.status configure.ac COPYING depcomp doc/ file.txt graphics/ metal1.png metal2.png INSTALL install-sh Makefile.am Makefile.in missing models/ human.obj ship1.obj ship2.obj music/ song1.ogg song2.ogg NEWS README sectors/ sector1.xml sector2.xml ships/ ship1.xml ship2.xml sounds/ src/ Makefile.am.template Makefile.in main.cpp ship.h ship.cpp space.h space.cpp Note: src/Makefile.am.template is generated using autogen.sh to produce src/Makefile.am... don't ask. - -- Ivan Vučica - -- Croatia -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFH/4rcsunNof3e6g8RAp8OAJoCPjvV7X48SaXJEEN/r1vf3jYr/wCfWGYH B/pd9VGS4wTUbwTk2v0zSM4= =rysn -END PGP SIGNATURE-
Re: Easiest way to Debianise a package?
* Ivan Vucica [EMAIL PROTECTED] [080411 18:18]: I'm looking for a smarter way to produce Debian packages for future games, out of SVN'ed, autotools-using projects. I'm looking for information for cases where I am the upstream. That means I could use tips with proper use of autotools to make generating DEBs easier; I'm still generally struggling with autotools. [...] So, I have an autotools project. Punching in make dist produces project-0.1.tar.gz. make distcheck also produces a valid executable provided that all libraries are installed. Data files are not (currently) mentioned anywhere in the autotools data files such as Makefile.am, configure.ac, etc. Questions: 1. What are your recommendations with regards to what to use to perform initial debianisation of the project? Meaning - what should I use? Just debhelper? CDBS? That depends whom you ask. Both has advantages and disadvantages. The biggest distadvantage of CDBS is that you have to know everything very good to be sure it does the right thing and still works tomorrow and not only by pure chance now. 2. Should data files be produced by same debianisation directory (by which I mean folder containing files copyright, rules, etc)? I don't understand the question. 3. Should source file generated by autotools contain the data files? Will that make debianisation any easier? That depends. Usually just having one .orig.tar.gz containing everything makes it easier for users compiling on their own (they just have to download a single file), for you if you want to put them into the same source package (which has the advantage of easier keeping them in sync in the archive, though the downsize that you only can upload new versions of program and data at the same time to Debian[1]). 4. In case my questions are wrong: What would be your steps for producing packages project and project-data, considering what I mentioned above and directory structure below? What would be your desires for upstream -- what should upstream do to make your life easier? In case everything is in the same source package (which I'd suggest), separating things at build time (and even only build the needed parts) is easier when arch-dependent and arch-independent parts are in separate directories and have their own Makefile's (in auto* by having their own Makefile.am doing the preparation and installing as opposed to having the top-level Makefile doing that) and no functionality in the top level dir (i.e. mostly only clean and things recursing into SUBDIRS there). What would you do after fetching SVN (not tar.gz) that contains data as below, and whose make dist would generate .tar.gz containing just sources? I guess I'd be confused but remember some games separate stuff and start reading the README. Note: src/Makefile.am.template is generated using autogen.sh to produce src/Makefile.am... don't ask. must. resist. the. urge Hochachtungsvoll, Bernhard R. Link [1] Though realistically, only both change at the same time usually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
On Fri, Apr 11, 2008 at 06:00:41PM +0200, Ivan Vucica wrote: I'm looking for a smarter way to produce Debian packages for future games, out of SVN'ed, autotools-using projects. You should check out the cdbs package which has an autotools helper. As an example, take a look at the rules for my couchdb package: https://svn.berlios.de/wsvn/erlang-pkg/couchdb/trunk/debian/rules?sc=1 At the top I include: include /usr/share/cdbs/1/rules/buildcore.mk include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk This is enough to build a basic autotools package for you automatically. HTH, -- Noah Slater - Debian GNU/Linux http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
Hello, I'm not a DD, but here are the first impressions I got from a quick review: - There are lots of unnecessary files (all the .ex stuff, empty ones, and otherwise unnecessary files). Also, yatc/trunk/debian/dirs lists some directories which probably don't need to be created explictly. - It's recommended to have a debian/watch file or a get-orig-source in debian/rules to download the upstream tarball. - Both packages have Priority: extra in debian/control. You probably want optional there; see /usr/share/doc/debian-policy/policy.html/ch-archive.html#s-priorities for an explanation about all possible values. - I haven't really checked, but on a first glance it seems like yatc misses some build dependencies. Have you tried if it builds correctly in a chroot (like for example with pbuilder)? - Why is the binary package tibia-data set as architecture dependent (Architecture: any means that it should be compiled for all available architectures; you probably want all there, which means that it is architecture independent and the .deb only needs to be build on one architecture). - Please don't say which packages it requires in yatc's description. - The descriptions could take some spell checking (an MMORPG - a MMORPG; 2d - 2D), and I think that they are too short. - You can remove lines 3-7 from debian/rules, the commented examples stuff in build-stamp and the comments from binary-arch. - tibia-data could suggest or recommend yatc. - The current standards version is 3.7.3, not 3.7.2. - This is only a personal preference, but if a package is licensed under GPL version 2 or later I prefer to refer to /usr/share/common-licenses/GPL instead of /usr/share/common-licenses/GPL-2 (was GPL links to the latest one, which is that one which the FSF recommends). But anyway, good work. I know that packaging can be quite difficult at start :). Regards, -- Siegfried-Angel Gevatter Pujals (RainCT) Ubuntu Developer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Easiest way to Debianise a package?
I'm not a DD, but I have a bit of advice: it seems that new users commonly will leave a file like debian/dirs in place because dh_make put it there. If you don't know what these files do, you can find out from the man pages for various debhelper commands. You can easily guess what manual page covers what you're looking for, i.e. *install are related to dh_install, *dirs are related to dh_installdirs, *cron are related to dh_installcron. To make multiple binary packages, I usually use .install files to handle which files go to each package. There's a relevant paragraph about this at [1], but it's pretty short. Also note that dh_install has --list-missing and --fail-missing options that might help you catch files that you forgot to install (though I haven't tried them yet, so I could be wrong). [1] http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-multiple-binary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
