Hi again, (moving to ubuntu-motu list, as I think this is a better place for this topic).
Am Montag 20 Februar 2006 21:00 schrieb Andrew Conkling: > Hey Stefan, thanks for the reply. > I didn't even think to check if it would be added; that's great to > hear! (It also spurs me on to get a few things worked on so that the > version in Dapper would be even more stable and usable. :) Great... however there is not really time left even for dapper to bring new versions in, since we are already in UpstreamVersionFreeze. That means, that we need to ask for an exception for all newer upstream versions and of course need a good reason for it (like fixing bugs). > > I understand that it can't be added to Breezy, but all the same, I > would like to create a package for Breezy that I can host on the > website (and install for my own use). I guess you could consider it > an exercise in package creation and edition. I'll look for a how-to > on modifying a Dapper package for use in Breezy. Ok, I'll try with a very quick guide: 0) install build-essential, pbuilder (you'll need to set this up to use breezy sources, but you seem to have already done this :). Packages you might also need are debhelper, cdbs, devscripts and fakeroot. 1) get the (dapper) sourcepackage. Option a) You can do this either with packages.ubuntu.com/pygmy -> dapper. At the bottom, there are three links (for native packages it would be two), that you need to download: the .dsc-file, the .orig.tar.gz and the .diff.gz. Run dpkg-source -x *dsc to extract the sourcepackage. Option b) The other way to do it, is to put "deb-src http://archive.ubuntu.com/ubuntu/ dapper universe" into your /etc/apt/sources.list and then "apt-get source pygmy". You will end up with the sourcepackage downloaded and already extracted (the .dsc, the .orig.tar.gz and the .diff.gz is there, as well as a directory with the extracted source-package which is named pygmy-<upstreamversion>). 2) Go into the top-src directory (pygmy-<upstreamversion>) and run dch -i. Thus you'll create a new entry in the changelog. Change the distribution-field (dapper) to breezy. You'll certainly also want to change the version to a lower version than the dapper package. This allows you to upgrade to the "real" dapper package, once you dist-upgrade to dapper. An possible version number would be 0.47-1homemade1. 3) You'll need to adjust the build-depends to match versions that are in breezy. Edit debian/control, where it says build-depends. For pygmy you'll only need to change the version of debhelper (which says >= 5.0.0) to >= 4.0.0. see (Annotation B). 4) Rebuild the source-package with "dpkg-buildpackage -rfakeroot -S -sa -us -uc". Thus you will get a new .dsc, .diff.gz (and now one .changes as well). 5) building the binary package Option a) (recommended) use pbuilder to build the binary package: "sudo pbuilder build pygmy_0.47-1homemade1.dsc". If all goes well, you'll have a .deb-package in /var/cache/pbuilder/result. Option b) (w.o. pbuilder): if you have installed all build-dependencies, you could also call "dpkg-buildpackage -rfakeroot -us -uc" in the top-source-directory. For homemade packages this doesn't really have drawbacks, however using pbuilder has the advantage, that you'll always use a clean build-environment, need to have build-depends set properly and pbuilder will recognize some other faults as well. Option c) (in case you want to debug the build process and/or need to patch some files): You can always call the make-targets of debian/rules in the topsrc-dir. In fact dpkg-buildpackage does nothing more than invoking a few of the rules in a given order. If you would call "make -f debian/rules binary", a .deb-package should be created right above top-src-dir. Calling these rules directly has the advantage, that if you need to patch some sourcecode files of a packages, you won't need to recompile all files again and again until the patch is right. 6) Publishing, once you have the .deb Option a): easy way: just upload the .deb to your webserver, and in case you also want to publish the source-package, upload the .dsc, .orig.tar.gz and .diff.gz as well (the .changes is not part of the sourcepackage, and only used if you verify the integrity of a sourcepackage, e.g. if I would upload a source-package to ubuntu's archive...) Option b): In a way that you can just enter a line in /etc/apt/sources.list: You could take a look at e.g. mini-dinstall, which provides a way to build the needed files/directory structure for a repository. (I will not go into the details, I don't know them by heart either and I guess that would be overkill right now ;) Annotation A: The versioned build-dependency debhelper is a bit special, since it is coupled together with debian/compat. I.e. if you set debian/compat to 5, you'll need debhelper (>= 5.0.0) and likewise reducing the needed debhelper version to (>= 4.0.0) you should adjust debian/compat to 4. I don't know the exact difference between these versions (you could look at debhelper's changelog for details), but afaik you have a very high chance that it'll work with compat level 4 as well. Phew... well maybe it's not a "quick" guide ;) > > OK, good to know. But once you have a package built and ready, how do > you use it on your stable installation? (I'm assuming you don't run > Dapper for day-to-day use.) Actually I've been running dapper for quite some time now, and currently, I consider it quite stable... (at the *beginning* of the release cycle, the development version however usually is far from stable ;) > Would you backport it yourself? Yes, probably. If it's a package that many ppl. would enjoy having, it might also be worth to report to the backporters team... However afaik, policy is that only packages can get backported, if no changes would need to be made. > Yes, I saw most of these pages, but they seem to have conflicting > information or different methods and styles, etc. After reading and > rereading them, I certainly didn't feel confident that I understood > very much. It's my plan to create a howto based on what I learn, so I > guess I'll just start collecting notes. :) That's great news... you might also want to check with the work the ubuntu-doc-team does or join forces with them. afaik they also work on a packaging guide. (irc-channel is #ubuntu-doc, they have a mailing list as well). Cheers, Stefan. -- Ubuntu-motu mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
