Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
On Fri, Apr 26, 2013 at 03:04:52PM +0100, Jonathan Dowland wrote: On Fri, Apr 26, 2013 at 02:20:53PM +0200, Carlos Alberto Lopez Perez wrote: dh_make -f ../foo-1.tar.gz dpkg-buildpackage I think one valid point the OP makes which each of these suggestions — in isolation — seem to miss, is there are *too many ways to do it*. The suggestions you (and others) make are great, but how discoverable are they to a newbie packager? Conversely, how (non-)discoverable are the myriad bad ways to do things (the hello package is a good example of this.) +1 -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130427192239.GD6353@tal
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
On 25/04/13 19:18, Wouter Verhelst wrote: Gentoo: - vim foo-1.ebuild; ebuild foo-1.ebuild manifest; emerge foo - That may look like oversimplification, but the contents of foo-1.ebuild really are very simple. By that rationale, building a Debian package simply requires mkdir debian; vim debian/rules; vim debian/control; dch --create; touch debian/copyright; dpkg-buildpackage. The contents of debian/rules and debian/control is really simple, dch helps you when creating a changelog, and an *empty* debian/copyright file is syntactically valid (though not semantically, of course). This can be even more simple: dh_make -f ../foo-1.tar.gz dpkg-buildpackage signature.asc Description: OpenPGP digital signature
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
On Fri, Apr 26, 2013 at 02:20:53PM +0200, Carlos Alberto Lopez Perez wrote: dh_make -f ../foo-1.tar.gz dpkg-buildpackage I think one valid point the OP makes which each of these suggestions — in isolation — seem to miss, is there are *too many ways to do it*. The suggestions you (and others) make are great, but how discoverable are they to a newbie packager? Conversely, how (non-)discoverable are the myriad bad ways to do things (the hello package is a good example of this.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426140452.GA18128@debian
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
From: Christian PERRIER bubu...@debian.org I'm definitely sure that a bug report is not the way to achieve anything here. Okay, continuing this on-list instead of in the bug report. Everyone, please keep me on the CC list, I missed half of these replies. As Wouter mentioned, coming up to $DISTRO and saying that you guys are doing things wrong and here is how you should do is like saying please throw away 20 years of accumulated experience and restart from scratch. I very much doubt it will ever happen. I am NOT trying to suggest that you throw away 20 years of work. I AM trying to suggest that even after 20 years, there are still some issues, which affect Ordinary Developers more than you. I'm not particularly interested in the following thread but I'm interested in keeping our BTS as clean as possible. Soclosing the bug report. My point for doing it as a bug was so that it would stay open instead of ending up lost in the archives of a list. I guess your motive is the exact opposite. From: Jonathan Dowland j...@debian.org I think one valid point the OP makes which each of these suggestions — in isolation — seem to miss, is there are *too many ways to do it*. The suggestions you (and others) make are great, but how discoverable are they to a newbie packager? Conversely, how (non-)discoverable are the myriad bad ways to do things (the hello package is a good example of this.) That is *exactly* my point. I have no doubt that someone familiar with the Debian infrastructure is capable of handling all of my use cases. The point is that not everyone is familiar with the Debian infrastructure, and people will give up if they have to look too hard. For example, I hadn't discovered dh_make; it's not in http://wiki.debian.org/IntroDebianPackaging From: Wouter Verhelst wou...@debian.org Put otherwise, going to one distribution and saying you guys are doing it all wrong, look at how $OTHER distribution is doing it, you should do it their way!!1! isn't very convincing. I was hoping the focus would not be on the fact that I mentioned a specific other distro. Is that why people are so hostile? That's a misconception. The hello package shows how to build a Debian package *without using any helper programs*. Almost nobody ever does that anymore; I'm not sure why that package still exists. Then remove it. If you want an example for how to really do things in practice, you should look at hello-debhelper. Its debian/rules and debian/rules-dh files are much simpler. From my experience at looking at debian/rules for packages I've tried to patch or upgrade, 'hello' is more typical than 'hello-debhelper'. Perhaps Debian should automatically file a bunch of bugs against packages with overly-complicated debian/rules? Or add a lintian warning or something. dpkg-scansources ... dpkg-scanpackages Good to know, but it's still more complicated than shipping ebuilds. all you need to do is ship the debian/ directory. This Just Works(TM). Not with dpkg-buildpackage, which everything I read seemed to indicate was the preferred way. - Run apt-get -d source package, fetch the new upstream source, run uupdate with the right arguments (read the manpage for the details). Unless it's something very complex, that will almost certainly work. Good to know. Not obvious at all. Of course, for a distressing number of packages, .orig.tar.gz is a repack, not the upstream's vanilla tarball. Would that make uupdate fail? If, OTOH, it *is* something very complex, then this... snip ... won't work either. Granted. From: Philip Hands p...@hands.com the deep joy of having users who patch packages into a state of uselessness, and then report bugs against the result without mentioning that they broke the package themselves. If those that expect to be able to do this sort of thing without consulting any documentation I'm not saying I expect to read no documentation. I'm saying that the documentation I read was not intuitive. And I'm certainly not stupid enough to expect support for something I broke on my own. I have enough of that from trying to support my own software. But the fact is: software as packaged by Debian *is* buggy and sometimes needs to be patched. Sometimes the bug is in the upstream version; sometimes it is in the Debian patches. From: Bernhard R. Link brl...@debian.org - Because of the above, debian/rules tries to know about backwards steps. What are backwards steps? The clean and unpatch targets Doing these manually is just asking for trouble, and you can't depend on the upstream makefile either. In Gentoo, 'ebuild foo-1.ebuild clean' just does rm -r /var/tmp/whatever/, and there is no explicit way to unpatch - just clean and extract without patching (ebuild foo-1.ebuild unpack for no patching; ebuild foo-1.ebuild prepare to also patch) - There are too many arcane commands that have to be called. ./debian/rules build fakeroot ./debian/rules binary Everything else is mostly convenience wrappers. I was
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
On 26-04-13 21:43, Ben Longbons wrote: From: Christian PERRIER bubu...@debian.org I'm definitely sure that a bug report is not the way to achieve anything here. Okay, continuing this on-list instead of in the bug report. Everyone, please keep me on the CC list, I missed half of these replies. As Wouter mentioned, coming up to $DISTRO and saying that you guys are doing things wrong and here is how you should do is like saying please throw away 20 years of accumulated experience and restart from scratch. I very much doubt it will ever happen. I am NOT trying to suggest that you throw away 20 years of work. I AM trying to suggest that even after 20 years, there are still some issues, which affect Ordinary Developers more than you. I realize (and agree!) that in some cases, Debian is more complex than it could be. However, you seem to have fallen in the fallacy to believe the familiar is easier than the unknown. That's just not true. [...] My point for doing it as a bug was so that it would stay open instead of ending up lost in the archives of a list. I guess your motive is the exact opposite. You'll need to convince people that there actually is a problem. Thousands of people make Debian packages every day, and certainly not all of them are Debian Developers. It's not *that* hard. [...] If you want an example for how to really do things in practice, you should look at hello-debhelper. Its debian/rules and debian/rules-dh files are much simpler. From my experience at looking at debian/rules for packages I've tried to patch or upgrade, 'hello' is more typical than 'hello-debhelper'. That doesn't match my experience. Perhaps Debian should automatically file a bunch of bugs against packages with overly-complicated debian/rules? Or add a lintian warning or something. I don't think that's possible. How are you going to define overly-complicated? How are you going to write code to decide that this other code is too complicated? That doesn't sound like it's even possible. dpkg-scansources ... dpkg-scanpackages Good to know, but it's still more complicated than shipping ebuilds. You can also just ship packages and install them with dpkg -i. The dpkg-scan* thingies is just extra infrastructure, similar to what you'd call portage overlays, if my understanding is correct. all you need to do is ship the debian/ directory. This Just Works(TM). Not with dpkg-buildpackage, Yes it does. I've done it. You need to make sure you're building as a native package, but other than that, there's no problem. which everything I read seemed to indicate was the preferred way. That's correct. - Run apt-get -d source package, fetch the new upstream source, run uupdate with the right arguments (read the manpage for the details). Unless it's something very complex, that will almost certainly work. Good to know. Not obvious at all. Of course, for a distressing number of packages, .orig.tar.gz is a repack, not the upstream's vanilla tarball. Would that make uupdate fail? It shouldn't, unless the .orig.tar.gz is laid out completely different. I've not seen that much in practice (if at all) [...] I'm not saying I expect to read no documentation. I'm saying that the documentation I read was not intuitive. Then perhaps the documentation you read wasn't the right documentation. For the benefit of improving that, could you let us know how you searched for it, and what you found? We should look into what went wrong there. [...] From: Bernhard R. Link brl...@debian.org - Because of the above, debian/rules tries to know about backwards steps. What are backwards steps? The clean and unpatch targets Doing these manually is just asking for trouble, and you can't depend on the upstream makefile either. Sure you can. unpatch is just patch -R. It's pretty hard to make that fail. As to upstream build systems, you can actually depend on them to have make clean or a make distclean working right--provided they're not using some home-rolled system, but are using something standard, like autotools or cmake or similar. There are certainly cases where that doesn't work, but those are bugs like any other, and most upstreams will take patches then. In the case where it's so bad that make clean doesn't work, you can always do a VPATH build, or simulate that with a symlink farm. That's not too hard. - It's not obvious how to modify the patch set directly. modify upstream files, call dpkg-source --commit Not what I call directly. Your patch management system seems optimized for changing things yourselves, rather than backporting upstream fixes. You can also just drop a patch file in the right directory and add its name to the series file... - There is no attempt at managing multiple source versions. First you say things are too complicated, then you complain about some obscure missing option I never found any use case for. Managing multiple source versions is essential, Nonsense.
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
CALP == Carlos Alberto Lopez Perez clo...@igalia.com writes: CALP This can be even more simple: CALP dh_make -f ../foo-1.tar.gz CALP dpkg-buildpackage And where does one find dh_make? Searching on goog suggests it would be part of debhelper. But it isn't: :; dpkg -L debhelper|grep dh_make /usr/bin/dh_makeshlibs /usr/share/man/de/man1/dh_makeshlibs.1.gz /usr/share/man/fr/man1/dh_makeshlibs.1.gz /usr/share/man/man1/dh_makeshlibs.1.gz /usr/share/man/es/man1/dh_makeshlibs.1.gz :; dpkg -l|grep debhelp|perl -pe 's/ +/ /g' ii debhelper 9.20120909 all helper programs for debian/rules -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m361z8dfdr@carbon.jhcloos.org
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
On 27/04/13 01:46, James Cloos wrote: CALP == Carlos Alberto Lopez Perez clo...@igalia.com writes: CALP This can be even more simple: CALP dh_make -f ../foo-1.tar.gz CALP dpkg-buildpackage And where does one find dh_make? Searching on goog suggests it would be part of debhelper. But it isn't: :; dpkg -L debhelper|grep dh_make /usr/bin/dh_makeshlibs /usr/share/man/de/man1/dh_makeshlibs.1.gz /usr/share/man/fr/man1/dh_makeshlibs.1.gz /usr/share/man/man1/dh_makeshlibs.1.gz /usr/share/man/es/man1/dh_makeshlibs.1.gz :; dpkg -l|grep debhelp|perl -pe 's/ +/ /g' ii debhelper 9.20120909 all helper programs for debian/rules -JimC Use apt-file to search which package contains a given file: $ apt-file search dh_make | grep /dh_make$ dh-make: /usr/bin/dh_make signature.asc Description: OpenPGP digital signature
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
[James Cloos] And where does one find dh_make? Searching on goog suggests it would be part of debhelper. But it isn't: Someone suggested 'apt-file', but in this case the simpler thing is: apt-cache search dh_make -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130427010928.gc4...@p12n.org
Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
Package: general Severity: wishlist Introduction: This is my attempt at explaining exactly what frustrations prevent me from doing anything with Debian packages, and how another distro (Gentoo) does it better. The fact that Gentoo is a source-based distro is irrelevant. I hope you will seriously consider the issues here for jessie, rather than replying we understand our system, if others don't that's their problem. First some definitions: Ordinary Developer: A debian user who is comfortable enough with command-line to install programs in /usr/local. They want to perform Simple Tasks. Simple Tasks: quick: Given a program that is not packaged for Debian and is not sufficiently useful to the general public to be worth the maintenance burden, install it such that the package manager knows about it. distribute: Given a completed set of package information for such a package, distribute it in a way that is easy for others to install. patch: Given a program with a buggy upstream release, apply a patch. revert: Given a program with buggy Debian packaging, revert a patch. upgrade: Given a program that is packaged in Debian, upgrade to an unpackaged version. The problems with the way Debian does it are: - debian/ is a subdirectory of the extracted source tree. - Because of the above, debian/rules tries to know about backwards steps. - There are too many files that need to be modified. - There are too many arcane commands that have to be called. - It's not obvious how to build except from apt-get source. - It's not obvious how to modify the patch set directly. - There is no attempt at managing multiple source versions. How Simple Tasks are approached: quick: Debian: - checkinstall is buggy, quirky, and has no upgrade path. - I still haven't figured out how to do this easily. Based on the 'hello' package, which is the simplest possible package, this requires writing a hundred lines of voodoo. A random sampling of existing package I've looked at agrees with this as a lower bound. Gentoo: - vim foo-1.ebuild; ebuild foo-1.ebuild manifest; emerge foo - That may look like oversimplification, but the contents of foo-1.ebuild really are very simple. distribute: Debian: - Still haven't figured out the right way. - I did find the 'dget' command that does some things. How was I supposed to know about this obscure command for a common use case? - You probably have to ship the whole huge .orig.tar.gz file, even though it's available on the internet under a different name, or even if it's really a git snapshot. Gentoo: - Put foo-1.ebuild somewhere online (typically in a git repo) - foo-1.ebuild contains the URL of the upstream tarball or git repo. patch: Debian: - After trying to make local changes, it said: dpkg-source --commit - But it is tedious when you already have a full patch from upstream. Gentoo: - Assume that you're competent enough to get ahold of a patch. - Add the patch to files/ (which is shared between all versions of the package, though you can of course use a different name). - Add the filename to the PATCHES=() variable, remanifest. revert: Debian: - no clue, it keeps trying to readd the changes and it's not obvious how to wipe the working tree. Gentoo: - Remove the filename from the PATCHES=() variable, remanifest. upgrade: Debian: - Hope it's in experimental. - Hope its experimental package is not broken. - Hope adding an experimental package won't break dependencies in the rest of your system. Gentoo: - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest - Typically, the source URL will automatically change based on the version number. If this is not the case, it is very obvious to fix. In conclusion: The current Debian way is complicated. The Gentoo way is simple. This is not tied to the fact that Gentoo is a source-based distribution, although that does encourage the right mindset. For evidence, look at the simplicity of: - http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/hello/hello-2.8.ebuild?view=markup - http://devmanual.gentoo.org/eclass-reference/ebuild/index.html Do NOT add yet another packaging tutorial or yet another set of helper scripts. There are too many as it is - they are just confusing and long. For the things that I'm talking about, Gentoo gets along just fine with a manpage - though they have a slightly longer guide for official packages. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425162202.31360.43414.reportbug@ben-laptop.local
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
Hi Ben, On 25-04-13 18:22, Ben Longbons wrote: Package: general Severity: wishlist [...long introduction snipped] How Simple Tasks are approached: quick: Debian: - checkinstall is buggy, quirky, and has no upgrade path. - I still haven't figured out how to do this easily. Based on the 'hello' package, which is the simplest possible package, That's a misconception. The hello package shows how to build a Debian package *without using any helper programs*. Almost nobody ever does that anymore; I'm not sure why that package still exists. If you want an example for how to really do things in practice, you should look at hello-debhelper. Its debian/rules and debian/rules-dh files are much simpler. this requires writing a hundred lines of voodoo. A random sampling of existing package I've looked at agrees with this as a lower bound. Gentoo: - vim foo-1.ebuild; ebuild foo-1.ebuild manifest; emerge foo - That may look like oversimplification, but the contents of foo-1.ebuild really are very simple. By that rationale, building a Debian package simply requires mkdir debian; vim debian/rules; vim debian/control; dch --create; touch debian/copyright; dpkg-buildpackage. The contents of debian/rules and debian/control is really simple, dch helps you when creating a changelog, and an *empty* debian/copyright file is syntactically valid (though not semantically, of course). distribute: Debian: - Still haven't figured out the right way. - I did find the 'dget' command that does some things. How was I supposed to know about this obscure command for a common use case? dget isn't something we expect people not involved in the development of Debian to use, so it's not documented in user-level documentation. For distributing source packages, you put them in a directory and call dpkg-scansources; users can then use apt-get source on that repository. Of course, for Debian you don't ship sources, you ship binaries. For that, there is dpkg-scanpackages. If you need to do a lot more than just one or two packages, there are other tools, such as reprepro, which allow you to just put files in a directory somewhere, and it's magically moved to the right place, with the right index files updated. If you're not interested in all that, you don't need to ship the .dsc or .deb files; if as an upstream you just want to ship debian packaging files, all you need to do is ship the debian/ directory. This Just Works(TM). - You probably have to ship the whole huge .orig.tar.gz file, even though it's available on the internet under a different name, or even if it's really a git snapshot. If you want to provide a Debian source package, then yes, that's what you need to do. However, you don't need to provide a full Debian source package if all you want to do is to allow people to easily build a .deb file. [...too bored to come up with a reply to these...] upgrade: Debian: - Hope it's in experimental. - Hope its experimental package is not broken. - Hope adding an experimental package won't break dependencies in the rest of your system. - Run apt-get -d source package, fetch the new upstream source, run uupdate with the right arguments (read the manpage for the details). Unless it's something very complex, that will almost certainly work. If, OTOH, it *is* something very complex, then this... Gentoo: - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest ... won't work either. - Typically, the source URL will automatically change based on the version number. If this is not the case, it is very obvious to fix. That's not an issue for Debian, as we ship upstream tarballs ourself, rather than relying on upstream for that. It has some downsides (as you correctly point out above), but also some upsides. This is one of them (there are more) In conclusion: The current Debian way is complicated. The Gentoo way is simple. For you. To this Debian developer who's never done any Gentoo work, the Gentoo way is complicated and the Debian way is simple. Put otherwise, going to one distribution and saying you guys are doing it all wrong, look at how $OTHER distribution is doing it, you should do it their way!!1! isn't very convincing. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51796574.9060...@debian.org
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
Wouter Verhelst wou...@debian.org writes: ... Put otherwise, going to one distribution and saying you guys are doing it all wrong, look at how $OTHER distribution is doing it, you should do it their way!!1! isn't very convincing. It's particularly unconvincing if one has witnessed the Gentoo BoF at this year's FOSDEM[1], in which they discussed the deep joy of having users who patch packages into a state of uselessness, and then report bugs against the result without mentioning that they broke the package themselves. We have a packaging system that rewards people that read up on the tools we provide for doing the simple tasks one might expect to be able to do with it. Conversely, it punishes those that don't. If those that expect to be able to do this sort of thing without consulting any documentation are encouraged to go elsewhere by this fact, then I'd say that's a feature, not a bug. Cheers, Phil. [1] I filmed that session: http://mirror.be.gbxs.net/video.fosdem.org//2013/crossdistro/Gentoo_BoF.webm The relevant bit starts at 11:10, with a very salient quote almost immediately from Petteri Räty (betelgeuse): I think user patching should be a _bit_ hard ... it's a support nightmare. Unless well thought out, all the bugs coming in to gentoo.org, debugging becomes ... complicated -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpSd9MDsYVYA.pgp Description: PGP signature
Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
+++ Ben Longbons [2013-04-25 09:22 -0700]: Package: general Severity: wishlist Introduction: This is my attempt at explaining exactly what frustrations prevent me from doing anything with Debian packages, and how another distro (Gentoo) does it better. The fact that Gentoo is a source-based distro is irrelevant. Not entirely irrelevant, as you admit yourself later. And I think you are rather more familiar with gentoo than debian so stuff seems simpler because you already know what to do. The converse applies too. patch: Debian: - After trying to make local changes, it said: dpkg-source --commit - But it is tedious when you already have a full patch from upstream. actually this is just the same in Debian as in Gentoo: put the patch in debian/patches and add its name to debian/patches/series Applying the patch to the sources first and doing dpkg-source --commit (*as above) also works (more reliably as it forces you to check that the patch actually applies here). Neither seems hard to me. Gentoo: - Assume that you're competent enough to get ahold of a patch. - Add the patch to files/ (which is shared between all versions of the package, though you can of course use a different name). - Add the filename to the PATCHES=() variable, remanifest. revert: Debian: - no clue, it keeps trying to readd the changes and it's not obvious how to wipe the working tree. Remove the patchname from debian/patches/series. Seems equivalent to your Gentoo example to me. Gentoo: - Remove the filename from the PATCHES=() variable, remanifest. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130425190902.ga2...@stoneboat.aleph1.co.uk
Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
* Ben Longbons brlongb...@gmail.com [130425 18:27]: The problems with the way Debian does it are: - debian/ is a subdirectory of the extracted source tree. Why do you think that is a problem? - Because of the above, debian/rules tries to know about backwards steps. What are backwards steps? - There are too many arcane commands that have to be called. ./debian/rules build fakeroot ./debian/rules binary Everything else is mostly convenience wrappers. - It's not obvious how to modify the patch set directly. modify upstream files, call dpkg-source --commit - There is no attempt at managing multiple source versions. First you say things are too complicated, then you complain about some obscure missing option I never found any use case for. How Simple Tasks are approached: Given a program that is not packaged for Debian and is not sufficiently useful to the general public to be worth the maintenance burden, install it such that the package manager knows about it. Debian: - checkinstall is buggy, quirky, and has no upgrade path. - I still haven't figured out how to do this easily. Based on the 'hello' package, which is the simplest possible package, this requires writing a hundred lines of voodoo. A random sampling of existing package I've looked at agrees with this as a lower bound. You can't have easy and high-quality at the same time. Most of the tools used for official Debian package have the minimal complexity needed for some quality. Apart from having someone write tools to simply create private packages there is not much that can be done here. (and from what you describe for Gentoo, I do not really see how a dh_make ; vim debian/* ; dpkg-buildpackage is more complicated than the Gentoo case). Given a completed set of package information for such a package, distribute it in a way that is easy for others to install. Debian: - Still haven't figured out the right way. There are many ways, because needs are different. - I did find the 'dget' command that does some things. How was I supposed to know about this obscure command for a common use case? dget is simply a convenience wrapper. Just have three files to download for a source package. Anyone can click at three links easily. - You probably have to ship the whole huge .orig.tar.gz file, even though it's available on the internet under a different name, or even if it's really a git snapshot. Sorry, but this is bullshit. If you want to make it easy for users, put the .orig.tar.gz there. References too external resources will always go stale and are and endless source of user frustration. Given a program with a buggy upstream release, apply a patch. Debian: - After trying to make local changes, it said: dpkg-source --commit - But it is tedious when you already have a full patch from upstream. patch -i patchfile ; dpkg-source --commit I thought it was about users knowing the basic command line utilities? Given a program with buggy Debian packaging, revert a patch. Debian: - no clue, it keeps trying to readd the changes and it's not obvious how to wipe the working tree. The very easy way: just revert the change and add another dpkg-source --commit The direct way: revert the change, remove the line from debian/patches/series The complicated way: use quilt or some other high-level tool. Gentoo: - Assume that you're competent enough to get ahold of a patch. - Add the patch to files/ (which is shared between all versions of the package, though you can of course use a different name). - Add the filename to the PATCHES=() variable, remanifest. Gentoo: - Remove the filename from the PATCHES=() variable, remanifest. Yeah, because every patch can simply be removed without any effects on the other patches, you can just apply any patches you need to the version you need. And if it doesn't you can just apply manually, fix it and produce a new clean patch. NOT, seriously. That you can just do stuff in your working directory, build and fix again iteratively in your working directory and finally have some working package is in my eyes one of the biggest strengths of Debian's package format w.r.t. low entrance and making it easy for unexperienced people to use Debian to meed their needs. Gentoo: - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest - Typically, the source URL will automatically change based on the version number. If this is not the case, it is very obvious to fix. your gentoo solution is the equivalent of copying the debian/ directory around. In conclusion: The current Debian way is complicated. The Gentoo way is simple. This is not tied to the fact that Gentoo is a source-based distribution, although that does encourage the right mindset. In
