The debian-private mailing list leak, part 1. Volunteers have complained about Blackmail. Lynchings. Character assassination. Defamation. Cyberbullying. Volunteers who gave many years of their lives are picked out at random for cruel social experiments. The former DPL's girlfriend Molly de Blanc is given volunteers to experiment on for her crazy talks. These volunteers never consented to be used like lab rats. We don't either. debian-private can no longer be a safe space for the cabal. Let these monsters have nowhere to hide. Volunteers are not disposable. We stand with the victims.

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

Re: Source uploads during development.



Dale Scheetz <dwarf@polaris.net> said:

>[... provide a mechanism for handling patchfiles instead of requiring
>     complete re-upload of sources (development distribution only) ...]
> Does anyone else think this is at all useful?

I think this would be useful.  Uploading multi-file, multi-megabyte packages
because of a one-byte change is (hmmmmm..... discards several descriptive
terms which come quickly to mind) inconvenient and inefficient.  In
fact, I'd like to develop this general theme of interim patches vs. full
updates a lot further, but not at this point.

Here's what occurs to me regarding source-patch-packages to source-packages --

The original source package name would have a .tar.gz extension.  The
maintainer would have provided a means to determine the source .tar.gz
file from the binary package (either through matching Package and Version
filename parts, or via the binary package Source field).

Subsequent uploads could have a .patchN.gz file (N being 1 for the initial
patch upload, and incremented for subsequent ones) instead instead of a
.tar.gz file.  a .tar.gz file and .patchN.gz files for a package would
be retained in the distribution until a new .tar.gz upload is seen,
at which point the previous .tar.gz file and all intervening .patchN.gz
files would be retired.  The Packages file could list (and md5sum?) the
current .tar.gz file and all current .patchN.gz files.

On download of the .tar.gz file and all .patchN.gz file, a simple standard
procedure should be used to apply the patches.  That'd probably be to
extract the .tar.gz file, apply the .patchN.gz files in sequence,
produce an patched-up-to-date .tar.gz file, and md5sum it.  That
seems to imply that a standard script would be needed to produce and
to apply debian source package patches, and a debian package needs
to appear which would supply that script.

At this point, the original maintainer's md5sum for his not-uploaded
up-to-date .tar.tz file would be needed for md5sum crosschecking, and the
procedure above lacks provision for him to have provided this information 
or for it to have been kept available on the distribution site so the
downloader could have it available for checking.

Yes, I think this would be useful, but it seems like there are quite a few
details to be worked out to make it solid and repeatable.  These details
would seem to involve involve at least the distribution maintainer, the
dchanges maintainer, probably the dftp and dpkg-ftp maintainers, a
maintainer for the new pkgpatch package, and the debian packaging guidelines
maintainer.

Also, I believe that several debian package maintainers have thoughts on
alternative source packaging formats.  Those would be affected as well
and, depending on whether any such alternative schemes are candidates
for implementation in the next half year or so, it might be better to
either hold off this proposal until the new source package scheme
stabilizes, or to address this proposal as part of implementation of
the new scheme.