Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
* Ben Longbons <brlongbons@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 half your cases you described the Gentoo way was much more
complicated from my experience. Perhaps being all l33t makes Gentoo
users able to work with so complicated solutions, though I'd suggest
they take a look at how Debian does it and try to improve their
process for inexperiences users at little in that regard.
Bernhard. Rlink
Reply to: