Re: request for Technical Committee ruling on Bug #109436
On Thu, Aug 23, 2001 at 01:13:01PM -0400, Raul Miller wrote:
> Ok, you seem to be asserting that the right thing, in this context,
> is to distribute the new tarball as if it were the old one.
That's correct. XFree86 upstream has no single, pristine source tarball
that we can use. How I create the source package is documented in
debian/copyright:
Package: xfree86
Obtained from: XFree86 CVS repository (anoncvs@anoncvs.xfree86.org:/cvs)
Upstream author(s): The XFree86 Project, Inc., et al.
Debian package author(s): Stephen Early, Mark Eichin, Branden Robinson
Debian modifications to upstream sources:
The following files were removed from the source package due to
non-DFSG-compliant licensing:
xc/fonts/scaled/Type1/COPYRIGHT.BH
xc/fonts/scaled/Type1/COPYRIGHT.IBM
xc/fonts/scaled/Type1/UTBI____.afm
[...]
See the debian/patches directory for all other changes to upstream
source.
For this change I simply need to add the files in xc/util/patch to this
list. (I forgot for the 4.1.0-3 upload and need to fix that in -4.)
> As you almost imply, the .dsc files for prior versions of the package
> will give improper md5sums for the new tarball.
Only prior Debian versions of the corresponding upstream version
(4.1.0):
xlibs | 4.0.3-3 | unstable | hurd-i386
xlibs | 4.0.3-4 | testing | alpha, arm, i386, m68k, powerpc, sparc
xlibs | 4.0.3-4 | unstable | arm
xlibs | 4.1.0-1 | unstable | m68k
xlibs | 4.1.0-2 | unstable | alpha, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
The .dsc's for hurd-i386 and arm in unstable will not be broken by this
change; neither will any of the packages in testing.
The .dsc's in unstable for the other architectures *will* be rendered
incorrect. I already covered this is in my initial request to the
Technical Committee. The archive maintainers could remove these
packages, or permit them to continue to exist in this inaccurate state
until they each upload 4.1.0-3, which they all have to do anyway.
> This strikes me as a problem, unless we're going to rely on us ignoring
> those md5sums.
It's only a problem if someone requests an .orig.tar.gz to be removed
and then doesn't want to an upload of anything to replace it. If they
do replace it, all architectures need to build the new package anyway.
If they do not, then I'd assume the package is being yanked altogether
and the binary packages need to be removed. We did this with xtetris a
few years ago.
> Are you willing to re-upload each of the prior debian releases, with fixed
> .dsc files, which have the md5sum of the new tarball? Or, if not all
> prior releases, at least those releases which are in the package pool?
> [I'm not saying this is the right solution -- I'm asking to you to look
> at what you're asking.]
On the one hand, I don't have a choice. On the other hand, this is
actually beyond my power, at least if I want to be thorough.
As I noted in the original bug report, I need to do this same surgery
for the xfree86v3 source package for testing/unstable, and (I think)
xfree86-1 in stable. These source packages contain DFSG violations and
I have no choice but to attempt to rectify the problem.
However, I *have no way* (that I know of) of rectifying the situation
with XFree86 4.0.3. These packages have already been superseded by more
recent uploads, and I don't know of any way to tell dinstall to accept
an upload of 4.0.3 again. We can, I guess, either choose to tolerate
the DFSG violation temporarily in expectation that 4.1.0 will ultimately
supersede the 4.0.3 packages in testing, or we need to yank the 4.0.3
packages altogether.
> Also: please tell me what's wrong with releasing a 4.1.0.,dfsg version.
Simply put, I don't want to do it. It's my package, and I like the name
and upstream version number as they are -- clear and unambiguous. I
have not forked the upstream sources, and I have no intention of doing.
The upstream authors are aware of my changes to their source package (we
have agreed to disagree on the font licensing issue which led to the
removal of some Type1 fonts from the source package -- see the
xfonts-scalable-nonfree source and binary packages). Furthermore, I do
not see my XFree86 packages as being substantially divergent from
upstream sources. My changes are documented in the copyright file.
If you were to ask the XFree86 Project, Inc., if what I am packaging for
Debian can legimately be called "XFree86", I am confident they would say
"yes" (they are quite tolerant of non-disruptive [i.e., "don't break
library ABI's"] customizations that distributors need to make). If it
would help you to make an informed decision in this matter, however, I
would urge you to ask them at <bod@XFree86.Org> (that is the address for
their Board of Directories, so as to faciliate an authoritative reply).
Furthermore, I do not recognize the authority of the archive
administrators to tell me what I may or may not name my package, as long
as it complies with policy (2.3.1) and doesn't collide with the name of
a package I don't maintain. Similarly, Chapter 4 of the Debian Policy
Manual is quite clear to what is acceptable in a package version number.
My package's name and version number are compliant with policy, and
beyond that I feel package maintainers should be left free to exercise
their discretion when it comes to stylistic details. See clause 3.1.1
of the Constitution ("An individual Developer may make any technical or
nontechnical decision with regard to their own work").
If the archive maintainers want to impose further restrictions, I think
they should have to submit a proposed amendment to the debian-policy
list.
Alternatively, the Technical Committee can exercise its authority to
update the Policy Manual accordingly. If the Technical Committee
decrees that it shall be Debian Policy that "package maintainers shall
name and version their packages as the archive maintainers dictate",
then I guess that's how it will be.
--
G. Branden Robinson | The noble soul has reverence for
Debian GNU/Linux | itself.
branden@deadbeast.net | -- Friedrich Nietzsche
http://www.deadbeast.net/~branden/ |
Reply to: