Bug#610298: phasing out tar-in-tar in source packages
Le Mon, Jan 17, 2011 at 11:49:49AM +0100, Stefano Zacchiroli a écrit : Considering all the above, it would be nice if policy could start to discourage tar-in-tar, at least with a should (not) requirement. A potentially appropriate place where to mention that seems to be §4.8 Restrictions on objects in source packages. Hi Stefano, I wonder if it isn't out of the scope of the Policy to recommend against practices that are anyway in strong decline. If the new packages that enter our archive do not use the tar-in-tar model unless they have a good reason, my feeling is that it is not necessary to emphasise that tar-in-tar should not be misused. This said, the Developers Reference already has an extensive section about upstream tarballs. Would't it be a better place to pass your message ? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610298: phasing out tar-in-tar in source packages
On Thu, 20 Jan 2011 11:39:26 +0100, Stefano Zacchiroli wrote: On Mon, Jan 17, 2011 at 08:24:25PM +0100, gregor herrmann wrote: And we have them for this reason; or put otherwise, we'd like to get rid of them which requires at least one of two things: [..] I don't mind deprecating bundles with tarballs but just recommending against them is not enough to make them go away :) That is of course a very good point. However, even this argument seems to be orthogonal to my proposal, in the following sense. *If* ftpmaster disallow too small packages, you need a technical way to coalesce several small upstream tarballs into a single Debian source package. That is something which you can do with source formats 3.0, so you would have a way to adhere to a SHOULD requirement against tar-in-tar. What am I missing here? Nothing technically; maybe you overlooked my implicit point that replacing a huge PITA (tar-in-tar plus home-grown building scripts) with a lesser PITA (unpacked tarballs plus an evolving build system that still won't overcome the fundamental problems of bundles) doesn't look like a huge benefit to me :) Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Sting: If You Love Somebody Set Them signature.asc Description: Digital signature
Bug#610298: phasing out tar-in-tar in source packages
On Mon, Jan 17, 2011 at 07:29:42PM +0100, Luk Claes wrote:
I don't think tar-in-tar source packages are the main obstacle to make
the assumption that apt-get source will deliver a clean separation
between upstream and 'local' changes. But I do agree that *if* 3.0
source packages are 'a should' then tar-in-tar should not be used anymore.
I don't see the logic of this. A SHOULD requirement is something you
should do per se, not because it's a consequence of something else. Even
if 3.0 is not a SHOULD requirement, you might be forced to use it by
some external condition, for instance because your upstream releases
.bz2 tarball and you don't want to repack them. Most maintainers in
those cases will go for 3.0 even if it's not a should requirement.
Hence I don't see why policy couldn't have a SHOULD requirement on
avoiding tar-in-tar even if it lacks a SHOULD requirement on 3.0 (which
I do think is too early to have). It might happen that maintainers will
then need to switch to 3.0 to adhere to the SHOULD requirement about
tar-in-tar, as it might happen today to maintainers that don't want to
repack a .bz2 upstream tarball. What would be the problem with that?
On Mon, Jan 17, 2011 at 08:24:25PM +0100, gregor herrmann wrote:
And we have them for this reason; or put otherwise, we'd like to get
rid of them which requires at least one of two things:
- ftp-masters accept very small packages (which they have declined to
do in the past, a recent request for the current policy is #606411)
- build tools provide a mechanism to build different sub-packages
separately. dpkg with source format v3 alone does not help here (beyond
unpacking etc. the tarballs), http://packages.qa.debian.org/pkg-components
is a first step but still very young [0]
I don't mind deprecating bundles with tarballs but just recommending
against them is not enough to make them go away :)
That is of course a very good point. However, even this argument seems
to be orthogonal to my proposal, in the following sense. *If* ftpmaster
disallow too small packages, you need a technical way to coalesce
several small upstream tarballs into a single Debian source
package. That is something which you can do with source formats 3.0, so
you would have a way to adhere to a SHOULD requirement against
tar-in-tar. What am I missing here?
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
signature.asc
Description: Digital signature
Bug#610298: phasing out tar-in-tar in source packages
Package: debian-policy Version: 3.9.1.0 Severity: wishlist tar-in-tar source packages, i.e. Debian source packages which contains upstream sources in compressed form and uncompress them on the fly during the build process, are a bit of a PITA. They are particularly so for tools who want to do source code analyses on the code shipped by debian (e.g. the recently started DACA project) but, more generally, violate a good faith assumption that apt-get source will deliver an unpacked source package where the user can grep through upstream source code. I haven't conducted an analyses of the amount of tar-in-tar source packages in the Debian archive (sorry about that), but per folklore it seems that there are very few such packages remaining in the archive. I guess this is so because tar-in-tar was mostly used to circumvent the lack of support for non-gzip compression in source packages, feature which is now provided by 3.0 source formats. Considering all the above, it would be nice if policy could start to discourage tar-in-tar, at least with a should (not) requirement. A potentially appropriate place where to mention that seems to be §4.8 Restrictions on objects in source packages. Thanks for considering and many thanks in advance, Cheers. PS en passant: appendix §C.3 seems to be out of date wrt source formats 3.0, but it's not normative, so it's not a big deal -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash debian-policy depends on no packages. debian-policy recommends no packages. Versions of packages debian-policy suggests: ii doc-base 0.9.5 utilities to manage online documen -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610298: phasing out tar-in-tar in source packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi I second the idea of phasing out source packages the old tar-in-tar, starting with a should (not) or a Recommend (against). :) ~Niels -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJNNFyXAAoJEAVLu599gGRCJz4P/3Uw70HMvfcypnmzVJVEXuBJ izKKugd/8rUY7DjC9oAbAHX5awGg7sOdWgaQpVHWnKXrLjYFny0p2Ua2D69HTL89 IJyf6NMsjtctP4ft2jJotfpYxJZhI7TgxpS2BkF952Wum85Z3MEVwor9yh+edziS YKtGDt2A46+2l7Py05hSEVArqkYaNTN1urNtJkNZec/6o2V3mWgDfEfRVM8Jww4J qo4/2EHPqyZvGa++FQ7bwFZMVk1E8PPlbQNjmEi/8NWHl+mWCyLZYXATHc3rtCpP 64YSSM7Y+WAsOgeSlb2FvZteCxnk8hOQE26lTqEt9i9arZelwS5dWM+IcvWe0feE vzPuIrgA3ONHYSEOUkhckyGLprjfddvqVRERjvalJrEzhrCGQuSDtda1KRl4pOU8 8N2e9BM4RJoQWpN1puc4y00ZJ0No7RT0gVxjFwZmVD7rOnqrZn5lMYdjjb82ne+k OTNSDnORmiwgmhBw+HC/aseJp/GwIvsSP1uHpufIxHZo+6PJqwrXXRKn+cMfnnxI 1GHwQpgQ9JgrV8XZxMefKNj5PtuuW3gtvhZuWsPEdOnxgXrAZOyKE0rGCl7XJD15 Lx7z5tofPRoMRCrwXvKyRwhifuX7bxlPVyP3pLoKIKsG027oKLTQPregEoi0Gh6J 2gQkVgF0FnE/YLbGK86M =S1iM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610298: phasing out tar-in-tar in source packages
On 01/17/2011 11:49 AM, Stefano Zacchiroli wrote: tar-in-tar source packages, i.e. Debian source packages which contains upstream sources in compressed form and uncompress them on the fly during the build process, are a bit of a PITA. They are particularly so for tools who want to do source code analyses on the code shipped by debian (e.g. the recently started DACA project) but, more generally, violate a good faith assumption that apt-get source will deliver an unpacked source package where the user can grep through upstream source code. I still remember that I implemented kind of a hack to make debdiff work with them :-) I don't think tar-in-tar source packages are the main obstacle to make the assumption that apt-get source will deliver a clean separation between upstream and 'local' changes. But I do agree that *if* 3.0 source packages are 'a should' then tar-in-tar should not be used anymore. I haven't conducted an analyses of the amount of tar-in-tar source packages in the Debian archive (sorry about that), but per folklore it seems that there are very few such packages remaining in the archive. I guess this is so because tar-in-tar was mostly used to circumvent the lack of support for non-gzip compression in source packages, feature which is now provided by 3.0 source formats. There are a couple of reasons for tar-in-tar source packages that I remember coming across: multiple upstream sources combined as one Debian source package, upstream does not provide gzip compressed tarball, upstream contains debian directory. All of these can be easily 'solved' by using 3.0 source formats and only by using these AFAICS. I'm quite indifferent on whether we should try to phase out these packages, though I do think that making 3.0 source formats 'a should' should be a precondition to not introduce possible inconsistencies. Cheers Luk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#610298: phasing out tar-in-tar in source packages
On Mon, 17 Jan 2011 19:29:42 +0100, Luk Claes wrote: tar-in-tar source packages, i.e. Debian source packages which contains upstream sources in compressed form and uncompress them on the fly during the build process, are a bit of a PITA. Indeed, they are -- we have a couple in the pkg-perl group. There are a couple of reasons for tar-in-tar source packages that I remember coming across: multiple upstream sources combined as one Debian source package, And we have them for this reason; or put otherwise, we'd like to get rid of them which requires at least one of two things: - ftp-masters accept very small packages (which they have declined to do in the past, a recent request for the current policy is #606411) - build tools provide a mechanism to build different sub-packages separately. dpkg with source format v3 alone does not help here (beyond unpacking etc. the tarballs), http://packages.qa.debian.org/pkg-components is a first step but still very young [0] I don't mind deprecating bundles with tarballs but just recommending against them is not enough to make them go away :) Cheers, gregor [0] cf. also http://raphaelhertzog.com/2010/09/07/how-to-use-multiple-upstream-tarballs-in-debian-source-packages/#comments http://lists.debian.org/debian-devel/2010/09/msg00208.html http://lists.debian.org/debian-devel/2010/09/msg00411.html etc. -- .''`. http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4 : :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of Free Software Foundation Europe `-NP: Tori Amos: Yes, Anastasia signature.asc Description: Digital signature
