On Sat, May 02, 2009 at 02:50:26PM +0300, Marius Vollmer wrote: > Making a Debian source package always felt cumbersome: dpkg-source just > tars up everything in front of it (I exaggerate, of course), and at > least I am not used to having to clean my source tree before making a > distribution tarball out of it.
I personally dislike the entire concept of "Debian-native" source packages. I would like it if all software in Debian had a split .orig/.diff. Even for real "native" sources, it makes things like backporting, reuse by others, and minor fixes, NMUs etc. rather simpler to do, and you get a diff of the changes to boot, which makes reintegration of the changes less time consuming (just review and apply the diff). Debian-native packages hinder collaboration and reuse by others. > Of course, Debian doesn't really need to be as careful about making > release tarballs as the GNU project: a Debian source package only needs > to work in Debian, and there is no need to include pre-built > documentation in the source, for example, because the tools to build it > are always there. While it might be common practice for Debian-originating packages to be packaged "Debian-native", I really do think that it makes sense to keep the "upstream" and "Debian" parts separate. For one thing, it separates formal releases of the real code from the packaging which, by its very nature, ends up being synched to Debian releases. It also encourages better separation of responsibilities and makes the packaging (upstream and Debian) easier to deal with. > Still, I feel that this area of what should and shouldn't be in a source > package is a bit under-addressed in Debian. (That is very likely only my > own ignorance. I learned the little I know about packaging in Maemo; > apologies might be in order for me speaking up on this list... :) > > On one end of the spectrum, a Debian source package could try to have as > little dependencies during build-time as possible. This would be nice > for distributions downstream of Debian that would have less trouble > importing Debian source packages. In this case, I think we would need > something like Source-Depends and making a source package would consist > of running the equivalent of "make maintainer-clean && autoreconf". Well, I do think this would make a certain degree of sense for people working /on/ the package, as opposed to just automated building of the package. However, keeping these fields up-to-date and ensuring their correctness would be an issue. The existing fields if incorrect will result in an FTBFS and prompt correction. These new ones are only used for manual work, and I'm not sure if it's worth the extra effort. Typically maintainers will be well aware of what the "extra" tools are they need for a complete development (as opposed to build) environment, and will ensure they are present. I'm not opposed to the concept, but I do have concerns about keeping them current and correct. As a general comment about your entire post, I think eliminating Debian-native packages would be a valuable goal. It will require developers/maintainers to work on correctly packaging and distributing their code like all other upstreams, rather than just dumping their working tree into a tarball and calling it a "release", which will increase the code/package quality and robustness. And of course, it makes it vastly easier for third parties to work with, making collaboration with downstream distributors much easier. (All the Debian-specific software I work on such as schroot and sbuild is all correctly autoconfiscated and packaged with a .orig.tar.gz, despite lintian moaning about it for -1 releases. It makes my life much easier.) > That is actually what got me started thinking about this in the first > place: I want to keep my sources (both upstream and packaged) in a VCS > without any generated files; I want to automatically create source > packages of a bare branch in a rich environment; and I want to > automatically compile these source packages in a poor environment (that > doesn't have all the tools I use during development). Look at schroot.git for an example of how this is done. You need to ./bootstrap the autotools in a "rich" environment, and then ./configure && make dist to get the upstream release tarball. I don't currently separate the debian packaging on a separate branch, but I do plan to in the future due to it making backporting and supporting multiple debian branches simultaneously much easier. This wouldn't be a hard change, but I do look forward to dpkg-source 3.0 (git) becoming allowed officially to allow this type of repo to be supported natively by the build infrastructure. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
