Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
2 views
Skip to first unread message
Ben Longbons
Apr 25, 2013, 12:30:02 PM4/25/13
to
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-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
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-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Wouter Verhelst
Apr 25, 2013, 1:20:02 PM4/25/13
to
Hi Ben,
On 25-04-13 18:22, Ben Longbons wrote:
> Package: general
> Severity: wishlist
[...long introduction snipped]
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...]
"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-dev...@lists.debian.org
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
> 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,
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.
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?
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.
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
> 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.
"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
> - Typically, the source URL will automatically change based on the
> version number. If this is not the case, it is very obvious to fix.
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.
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/51796574...@debian.org
Philip Hands
Apr 25, 2013, 3:30:01 PM4/25/13
to
Wouter Verhelst <wou...@debian.org> writes:
...
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
...
> 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
> it all wrong, look at how $OTHER distribution is doing it, you should do
> it their way!!1!" isn't very convincing.
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
Wookey
Apr 25, 2013, 3:40:02 PM4/25/13
to
+++ Ben Longbons [2013-04-25 09:22 -0700]:
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-dev...@lists.debian.org
> 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.
> 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.
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.
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.
Gentoo example to me.
> Gentoo:
> - Remove the filename from the PATCHES=() variable, remanifest.
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/2013042519...@stoneboat.aleph1.co.uk
Debian Bug Tracking System
Apr 26, 2013, 1:30:01 AM4/26/13
to
Your message dated Fri, 26 Apr 2013 07:10:37 +0200
with message-id <2013042605...@mykerinos.kheops.frmug.org>
and subject line Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
has caused the Debian Bug report #706160,
regarding general: it should be easier for ordinary developers to work with Debian packages
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
706160: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706160
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
with message-id <2013042605...@mykerinos.kheops.frmug.org>
and subject line Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages
has caused the Debian Bug report #706160,
regarding general: it should be easier for ordinary developers to work with Debian packages
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
706160: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706160
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bernhard R. Link
Apr 26, 2013, 1:40:02 AM4/26/13
to
* Ben Longbons <brlon...@gmail.com> [130425 18:27]:
> - 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:
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.
> - 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.
I thought it was about users knowing the basic command line utilities?
> Given a program with buggy Debian packaging, revert a patch.
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.
>
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
> 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?
> - 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 arcane commands that have to be called.
fakeroot ./debian/rules binary
Everything else is mostly convenience wrappers.
> - It's not obvious how to modify the patch set directly.
> - There is no attempt at managing multiple source versions.
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.
> 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
> - 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.
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.
> - 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?
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.
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
> - After trying to make local changes, it said: dpkg-source --commit
> - But it is tedious when you already have a full patch from upstream.
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
> - no clue, it keeps trying to readd the changes and it's not obvious
> how to wipe the working tree.
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
> - Remove the filename from the PATCHES=() variable, remanifest.
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.
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.
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
Carlos Alberto Lopez Perez
Apr 26, 2013, 8:30:02 AM4/26/13
to
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:
>> 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).
>
dh_make -f ../foo-1.tar.gz
dpkg-buildpackage
Jonathan Dowland
Apr 26, 2013, 10:10:02 AM4/26/13
to
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/20130426140452.GA18128@debian
> 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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Ben Longbons
Apr 26, 2013, 4:10:01 PM4/26/13
to
From: Christian PERRIER <bub...@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 <jm...@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.
>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>
From: Philip Hands <ph...@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.
>
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 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:
>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 <woo...@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>
Using debian/rules binary, it ignores the patch list and uses what's in
the working tree; using dpkg-buildpackage, it errors out.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CA+XNFZMJ-2kAtHJOnyzAcWM4...@mail.gmail.com
>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 <jm...@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.)
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.
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.
>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.
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).
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.
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 <ph...@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
>consulting any documentation
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"?
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.
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
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.
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.
>> 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.
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.
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.
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.
>The direct way: revert the change, remove the line from debian/patches/series
>The complicated way: use quilt or some other high-level tool.
>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.
>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.
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.
.orig.tar.gz, extract it properly, reapply patches, etc.
From: Wookey <woo...@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
>Remove the patchname from debian/patches/series. Seems equivalent to your
>Gentoo example to me.
And the working directory gets the patches applied how?
>Gentoo example to me.
Using debian/rules binary, it ignores the patch list and uses what's in
the working tree; using dpkg-buildpackage, it errors out.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Wouter Verhelst
Apr 26, 2013, 6:00:02 PM4/26/13
to
On 26-04-13 21:43, Ben Longbons wrote:
> From: Christian PERRIER <bub...@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
> From: Christian PERRIER <bub...@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.
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.
> of ending up lost in the archives of a list. I guess your motive is the
> exact opposite.
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.
>> 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.
"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.
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,
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.
>> - 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?
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.
> the documentation I read was not intuitive.
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.
>>> - 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.
"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.
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,
> e.g. when trying
> to figure out in which versions a bug is.
>>> - 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.
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.
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
>> 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?
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.
> around.
> The difference being that in Debian, you *also* have to get a new
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.
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/517AF8A3...@debian.org
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
James Cloos
Apr 26, 2013, 8:00:01 PM4/26/13
to
>>>>> "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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/m361z8d...@carbon.jhcloos.org
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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Carlos Alberto Lopez Perez
Apr 26, 2013, 8:10:02 PM4/26/13
to
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:
>>>>>> "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
>
$ apt-file search dh_make | grep /dh_make$
dh-make: /usr/bin/dh_make
Peter Samuelson
Apr 26, 2013, 9:10:01 PM4/26/13
to
[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:
>
> Searching on goog suggests it would be part of debhelper. But it isn't:
apt-cache search dh_make
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Chris Bannister
Apr 27, 2013, 3:30:01 PM4/27/13
to
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
> 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.)
--
"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-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages