Synching packaging-dev with Developers' Reference (Re: packaging-dev meta package)
I understand intent is a good one but the proposed list seems not so
well thought though. Unless inclusion criteria is clearly defined, it
becomes just another random bloated list of packages.
My first reaction was that, if we are to have such package, we just need
to depends on build-essential and devscripts. So why cdbs and
bzr-builddeb were listed there when I do not see devscripts and
git-buildpackage. .... like others already posyed here.
I looked into Debian policy and developers-reference just to be sure.
Then, I realized that it may be a good idea to make a longer list of
packages for packaging as long as it is properly maintained together with
the list in the developers-reference APPENDIX.
Here is how I came to this conclusion.
Per policy: 4.2 Package relationships we all install build-essential
Depends: libc6-dev | libc-dev, gcc (>= 4:4.4.3), g++ (>= 4:4.4.3), make,
dpkg-dev (>= 1.13.5)
Adding Recommends/Suggests to build-essential may serve similar purpose
but may not be the right place.
There are another list in Developers reference "Appendix A. Overview of
Debian Maintainer Tools". There, quite a bit of packages are listed for
Anyway, all DD should have read these and installed packages and
installed pertinent dependency packages. "devscripts" is one of it and
that includes many dependency. So they had good packages on their
On Thu, May 26, 2011 at 10:05:42PM +0200, Benjamin Drung wrote:
> As a starting point packaging-dev would depend on
Yes. But the rest seems too arbitrary.
> ubuntu-dev-tools (only on Ubuntu systems)
If this kind of list to be maintainable, I think it is good idea to be
packaged by the same party as the best practice document maintainer ..,
i,e, developers-reference using its content. Then having such package
may have some reason.
For example, list should be more like:
Recommends: and Suggests:
Chose from list all the tools in Developers' reference Appendix.
If needed, update document too. Most of them should be "Suggests".
A.1.1. dpkg-dev (not needed since build-essential)
A.2.1. lintian (good candidate for Recommends)
A.3.1. debhelper (good candidate for Recommends)
A.3.3. yada (maybe as dh-make|yada)
A.3.4. equivs (This pulls in debhelper)
(Here, git-buildpackage may needs to be added soon.)
A.5.2. dput (A.5.3. dcut)
A.6.1. devscripts (good candidate for Recommends)
(autoconf and automake are mentioned but cmake is not mentioned
This may be a section to ask update to include cmake.)
A.8.2. debiandoc-sgml (Maybe not in suggests since it is deprecated.)
By making these 2 things linked, we have trackable rationale.
Otherwise, we will have badly maintained suggestions.
> Do you like the idea or not? Do you have a better name for the meta
> package? Should something added to or removed from the dependency list?
Please note that devscripts almost serves as a list of such de facto
list on Debian. Many debated choices are already included there as
Recommends or Suggests and may have been pulled in against your will :-).
Recommends: at, curl | wget, dctrl-tools, debian-keyring, debian-maintainers,
dput | dupload, equivs, fakeroot, gnupg, libauthen-sasl-perl,
libcrypt-ssleay-perl, libparse-debcontrol-perl, libsoap-lite-perl,
libterm-size-perl, libtimedate-perl, liburi-perl, libwww-perl,
libyaml-syck-perl, lintian, lsb-release, bsd-mailx | mailx, man-db,
patch, patchutils, quilt, ssh-client, strace, unzip, wdiff,
www-browser, subversion | cvs | darcs | tla | bzr | git-core |
mercurial, lzma, xz-utils, sensible-utils, libjson-perl
Suggests: build-essential, cvs-buildpackage, devscripts-el, gnuplot,
libfile-desktopentry-perl, libnet-smtp-ssl-perl (>= 1.01-2), mutt,
(Here I see some needs to update such as git-core -> git, ... too.)
I know we do not need debhelper nor quilt to make package. But most
of us use them. Having some list to pull these highly recommended
packages as recommends may be good idea as long as they are well
Please note that developers-reference is maintained as group in very
methodical way. The maintenance of this kind of list belongs to such
PS: I have recently updated developer package list for novice developer
in "Debian New Maintainers' Guide".
(This is not official list of recommendation but a mere suggestion by
few DDs. That is why I mentioned developers-reference.)