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 <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 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" <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.
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.
> e.g. when trying
> to figure out in which versions a bug is.
snapshot.debian.org
>>> - 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.
dpkg-source -x
any documentation which you may have read should have told you that.
>> 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.
That's what we do too. The only difference is that we give it a very
specific name, which gentoo doesn't do; but that doesn't really matter
all that much.
The reason that orig.tar.gz needs to be there is so that the build
system can know which files are from the original tarball, and which
ones go to the debian.tar.gz (or the diff.gz in the 1.0 source package
format), and so that the .dsc can contain the checksums of that
orig.tar.gz file.
[...]
>> 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?
Just because you're writing a patch doesn't mean it has to be specific
to Debian...
[...]
>> 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.
uupdate does that for you.
[...]
--
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.
Reply to: