Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
From: Christian PERRIER <bubulle@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.
>
>So....closing 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 <jmtd@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 <wouter@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 <phil@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" <brlink@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 also talking about the implementation of debian/rules, though
that fakeroot is annoying (in gentoo, the only part of building that
needs root is actually merging the image into the filesystem,
not creating merely creating the image)
>> - 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.
>> - 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, e.g. when trying
to figure out in which versions a bug is. I did not know about uupgrade
(how would I?), but that only does one-way upgrades.
Of course, since I found that debian/rules binary does NOT require the
orig.tar.gz (I was using dpkg-buildpackage), it's not as bad as I thought.
>You can't have easy and high-quality at the same time.
Nonsense.
>> 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.
For one case, it looks like the answer to this is using
fakeroot debian/rules binary instead of dpkg-buildpackage, to avoid
the need to distribute a a .orig.tar.gz (we may be in a git repo),
though there will still probably be a lot of messing around with version
numbers.
For another case, using dget on the .dsc looks like the best solution.
None of this was obvious from reading the documentation I could find.
>> - 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.
But it's not at all obvious how to make the extraction and patching
happen properly. Remember that the insides of .orig.tar.gz might NOT
follow debian's naming convention, and I'm still not sure just what
part of the autoextract is responsible for applying patches.
>> - 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.
For released packages, Gentoo tries to find all downloads on their own
mirrors first, of course.
And I am quite confident in the ability of sites like SourceForge, GitHub,
and Google Code to continue hosting the downloads.
Also, do not underestimate the power of being able to specify a git://
URL (plus a commit id, of course) isntead of an http:// URL.
>> Given a program with buggy Debian packaging, revert a patch.
>> Debian:
>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.
Okay, so simple way.
>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.
This is usually true enough in practice.
>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.
Am I wrong in saying that, most of the time, patches should be backported
from upstream, rather than being specific to Debian? While there certainly
is a place for a program that diffs a tarball against a working tree,
using it exclusively encourages divergence from upstream.
>your gentoo solution is the equivalent of copying the debian/ directory
around.
The difference being that in Debian, you *also* have to get a new
.orig.tar.gz, extract it properly, reapply patches, etc.
From: Wookey <wookey@wookware.org>
>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.
I have been using Debian-based systems for 5 years as my primary OS;
Gentoo for 3 years but not as my primary OS.
>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
><snip>
>Remove the patchname from debian/patches/series. Seems equivalent to your
>Gentoo example to me.
And the working directory gets the patches applied how?
Using debian/rules binary, it ignores the patch list and uses what's in
the working tree; using dpkg-buildpackage, it errors out.
Reply to: