[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to include information about a source package ?

Bart Martens <bartm@knars.be> writes:
> On Sun, Apr 30, 2006 at 12:05:19AM -0700, Russ Allbery wrote:

>> One advantage of insisting on a get-orig-source target

> Do you insist on a get-orig-source target while sponsoring? It's
> currently optional according to the debian-policy.
> http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules

I don't find get-orig-source as useful for normal packages that don't
require repackaging of upstream source.  In that case, for the most part,
I don't think it's worth the effort.

I haven't yet sponsored a package with a repackaged upstream source.  If I
did, I'd at least strongly encourage a get-orig-source target.  It's
possible that I could be talked out of it, though.  I'd have to see what
the specific case is.

>> as part of the review is that it ensures that the derivation of the
>> .orig.tar.gz file is automated and reproducible, making it easier and
>> quicker to package the *next* upstream release of the software.

> The next upstream .tar.gz may be completely different.  Trying the
> get-orig-source target on a new .tar.gz without first having a look
> inside that new .tar.gz before, can make a mess.

It *may* be, but that's true of everything related to Debian packaging.
In practice, usually repackaging involves deleting specific portions of
the upstream release.  For example, here's the get-orig-source target for

# Download the upstream source, merge in the doc tarball, and do the
# repackaging that we have to do for DFSG reasons.  This assumes AFS is
# mounted, as it's generally only used by the package maintainers.
        cp $(UPSTREAM)/openafs-$(VERSION)-src.tar.bz2 .
        tar xjf openafs-$(VERSION)-src.tar.bz2
        rm openafs-$(VERSION)-src.tar.bz2
        cp $(UPSTREAM)/openafs-$(VERSION)-doc.tar.bz2 .
        tar xjf openafs-$(VERSION)-doc.tar.bz2
        rm openafs-$(VERSION)-doc.tar.bz2
        rm -r openafs-$(VERSION)/src/packaging/MacOS
        rm -r openafs-$(VERSION)/src/WINNT
        tar cf openafs_$(DEBVERS).orig.tar openafs-$(VERSION)
        rm -r openafs-$(VERSION)
        gzip -9 openafs_$(DEBVERS).orig.tar

Other than changing $(VERSION) and $(DEBVERS), this has worked the same
for multiple upstream releases and I doubt anything significant is going
to change in the near future.

Eventually, there will always be an upstream release that breaks parts of
the packaging and requires careful attention when upgrading.

> Also, repackaging a .orig.tar.gz should be avoided.  It is better to
> encourage the upstream author to make the repackaging unnecessary before
> the next upstream .tar.gz is released.  That is, of course, not always
> possible.

Oh, certainly.  Always use the virgin upstream sources whenever possible.
I think we're all agreed on that.

I repackage openafs, for instance, because upstream distributes OpenAFS as
two separate tarballs and dpkg support for multiple upstream source
tarballs is not yet available, because there's *one* file in the MacOS
packaging that Debian cares about not at all which is covered under a
non-free license, and because, since I'm repackaging anyway, I may as well
drop the (uninteresting for Debian) giant WINNT directory and save 8MB of
archive space.

>> Obviously if I can't convince anyone here, there's no point in filing a
>> bug against the Developer's Reference for a change that has no
>> consensus.

> Filing such a bug and starting a discussion on other mailing lists
> (debian-devel?) could make more people participate in the discussion.
> Maybe the consensus becomes what you want, I don't know that now.  But I
> guess that some parts of what we're discussing now may already have been
> discussed in the past years, so doing some googling before may be wise.

This is probably true.  :)  That's one of the reasons why I've not taken
it to a broader forum; it's not yet clear to me whether I have a case
worth bothering people who aren't already reading this thread.

> A sponsor should not trust a get-orig-source target written by the
> sponsoree (is that correct english?).  The sponsor should redo the
> repackaging of the .orig.tar.gz step by step to verify whether each step
> is appropriate.

I think my point is that I can do that by reviewing the contents of the
get-orig-source target line by line and hence know exactly what it does,
and then run it and make sure I get the same thing that the sponsoree got.

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: