<strong>Report forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: [proposal] disallow multi-distribution uploads
Reply-To: Ben Collins <bcollins@debian.org>, 90511@bugs.debian.org
Resent-From: Ben Collins <bcollins@debian.org>
Orignal-Sender: Ben Collins <bmc@visi.net>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 04:18:01 GMT
Resent-Message-ID: <handler.90511.B.98514756816616@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by bugs@bugs.debian.org id=B.98514756816616
          (code B ref -1); Wed, 21 Mar 2001 04:18:01 GMT
Date: Tue, 20 Mar 2001 23:06:02 -0500
From: Ben Collins <bcollins@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Message-ID: <20010320230602.X28602@visi.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
Sender: Ben Collins <bmc@visi.net>
Delivered-To: submit@bugs.debian.org


--fUYQa+Pmc3FrFX/N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Package: debian-policy


Summary:

Policy should disallow uploads for multiple distributions. Specifically
this means same version uploads to "stable unstable".


History:

Running a buildd, I have the problem of builds that come in for stable
and unstable. Currently this means the buildd performs the compile on
stable, and either uploads to "stable unstable", or as it were
previously, it uploaded to stable, and then asked the buildd admin to
perform the same upload to unstable. That used to work, and it used to
be a needed feature for "frozen unstable" uploads. We do not support
this anymore, since we do not have a "frozen" dist to upload to.

Also, dinstall (AKA katie), disallows seperate uploads of the same
version to seperate distributions. The pool layout means there is only
one copy of the same version, and the pgsql database tracks which
distribution this is supposed to be in.

It's my opinion that same version uploads to stable/unstable are harful
to archive and distribution integrity. I've talked this over with James
Troup, and he seems to agree with the points below, and is considering
enforcing them via dinstall checks. My intention is to get the weight
of policy behind this.


Technical reasoning:

1) Building for "stable unstable" means that 99% of the time the build
is performed on a box running "stable". So the package will be compiled
against "stable" libraries. Now we all know that most of the major
libraries will go on to new major versions between releases. Ncurses (4
to 5 between slink and potato), readline (2 to 4 between slink and
potato), gnome (several revisions during potato development, and others
now), libstdc++ (which changes with the libc6 major upgrades), etc...

Now, a lot of libraries keep an oldlib around for backward compatibility
of packages that have not been recompiled for the newest version of the
lib. This is a less than optimal situation since it must be maintained
just like any other package. If libncurses4 is in stable, and
libncurses5 is in unstable (with the 4 version around only for backward
compat), then builds in unstable should be using the libncurses5.
However, someone compiling for "stable unstable" uneedingly prolongs
this oldlib's life.

2) Policy changes. This is probably the worst case. We all know that
policy abiding build-helpers change between releases just like policy
does. Take the usr/doc->usr/share/doc changeover scripts, and the X
default scripts used and hardcoded during the build. Building on stable
and unstable produces 2 different packages, abiding by two different
policies.

So by allowing stable built apps into unstable, we prolong policy
changes for the distributions aswell.

3) Build failures. It is commonly the case that a package built on
stable will not compile on unstable, even though it works runtime wise.


Issues:

The only issue I forsee is the likely even of where an upload to stable
and unstable is desired. I suggest that policy specify this to be done:

If package "blah" is in stable/unstable of version 1.0-1 (meaning it has
not changed since stable was released) and an upload must be done for
both stable and unstable of 1.0-2, then the stable upload must be
1.0-1.90 and unstable must be 1.0-2. This is similar to an NMU. The
reason for the .90 is similar in spirit to how glibc starts a
pre-release series (IOW, pre-releases for 2.2 start at 2.1.90).


Caveats:

This policy in no way forces compiled for unstable to be against the
unstable dist. IOW, uploading to unstable does not mean it was compiled
against unstable. That is a little harder to enforce. Perhaps we need a
way to tell dinstall that certain deps are obsoleted for a dist (IOW,
tell dinstall that packages targeted for unstable cannot dep on
libncurses4). However, that is another proposal altogether, and is not
the aim of this one.

--=20
 -----------=3D=3D=3D=3D=3D=3D=3D-=3D-=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=
=3D=3D=3D-----------=3D=3D=3D=3D=3D------------=3D-=3D------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=3D=3D=3D=3D=3D=3D=3D=3D=3D------=3D=3D=3D=3D=3D=3D=3D-------------=3D=
-=3D-----=3D-=3D=3D=3D-=3D=3D=3D=3D=3D=3D-------=3D--=3D---'

--fUYQa+Pmc3FrFX/N
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Ben Collins <bcollins@debian.org>

iD8DBQE6uCiqfNc/ZB4E7C0RAqXwAJ497nIUFnhGOwZYk4IP+5Zs80kUnACfWhlk
E021fm/qqHcgPmRQP+Uk/MQ=
=eV4C
-----END PGP SIGNATURE-----

--fUYQa+Pmc3FrFX/N--




<strong>Acknowledgement sent</strong> to <code>Ben Collins &lt;bcollins@debian.org&gt;</code>:<br>
New Bug report received and forwarded.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Ben Collins <bcollins@debian.org>
Subject: Bug#90511: Acknowledgement ([proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B.98514756816616.ack@bugs.debian.org>
In-Reply-To: <20010320230602.X28602@visi.net>
References: <20010320230602.X28602@visi.net>
X-Debian-PR-Message: ack 90511

Thank you for the problem report you have sent regarding Debian.
This is an automatically generated reply, to let you know your message has
been received.  It is being forwarded to the developers mailing list for
their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to submit further information on your problem, please send
it to 90511@bugs.debian.org (and *not* to
bugs@bugs.debian.org).

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at submit) by bugs.debian.org; 21 Mar 2001 04:06:08 +0000
From bmc@visi.net Tue Mar 20 22:06:08 2001
Return-path: <bmc@visi.net>
Received: from ppp41.ts6-2.newportnews.visi.net (blimpo.internal.net) [209.8.199.41] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fZst-0004Jw-00; Tue, 20 Mar 2001 22:06:07 -0600
Received: from bmc by blimpo.internal.net with local (Exim 3.22 #1 (Debian))
	id 14fZsp-0000qr-00
	for <submit@bugs.debian.org>; Tue, 20 Mar 2001 23:06:03 -0500
Date: Tue, 20 Mar 2001 23:06:02 -0500
From: Ben Collins <bcollins@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: [proposal] disallow multi-distribution uploads
Message-ID: <20010320230602.X28602@visi.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
Sender: Ben Collins <bmc@visi.net>
Delivered-To: submit@bugs.debian.org


--fUYQa+Pmc3FrFX/N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Package: debian-policy


Summary:

Policy should disallow uploads for multiple distributions. Specifically
this means same version uploads to "stable unstable".


History:

Running a buildd, I have the problem of builds that come in for stable
and unstable. Currently this means the buildd performs the compile on
stable, and either uploads to "stable unstable", or as it were
previously, it uploaded to stable, and then asked the buildd admin to
perform the same upload to unstable. That used to work, and it used to
be a needed feature for "frozen unstable" uploads. We do not support
this anymore, since we do not have a "frozen" dist to upload to.

Also, dinstall (AKA katie), disallows seperate uploads of the same
version to seperate distributions. The pool layout means there is only
one copy of the same version, and the pgsql database tracks which
distribution this is supposed to be in.

It's my opinion that same version uploads to stable/unstable are harful
to archive and distribution integrity. I've talked this over with James
Troup, and he seems to agree with the points below, and is considering
enforcing them via dinstall checks. My intention is to get the weight
of policy behind this.


Technical reasoning:

1) Building for "stable unstable" means that 99% of the time the build
is performed on a box running "stable". So the package will be compiled
against "stable" libraries. Now we all know that most of the major
libraries will go on to new major versions between releases. Ncurses (4
to 5 between slink and potato), readline (2 to 4 between slink and
potato), gnome (several revisions during potato development, and others
now), libstdc++ (which changes with the libc6 major upgrades), etc...

Now, a lot of libraries keep an oldlib around for backward compatibility
of packages that have not been recompiled for the newest version of the
lib. This is a less than optimal situation since it must be maintained
just like any other package. If libncurses4 is in stable, and
libncurses5 is in unstable (with the 4 version around only for backward
compat), then builds in unstable should be using the libncurses5.
However, someone compiling for "stable unstable" uneedingly prolongs
this oldlib's life.

2) Policy changes. This is probably the worst case. We all know that
policy abiding build-helpers change between releases just like policy
does. Take the usr/doc->usr/share/doc changeover scripts, and the X
default scripts used and hardcoded during the build. Building on stable
and unstable produces 2 different packages, abiding by two different
policies.

So by allowing stable built apps into unstable, we prolong policy
changes for the distributions aswell.

3) Build failures. It is commonly the case that a package built on
stable will not compile on unstable, even though it works runtime wise.


Issues:

The only issue I forsee is the likely even of where an upload to stable
and unstable is desired. I suggest that policy specify this to be done:

If package "blah" is in stable/unstable of version 1.0-1 (meaning it has
not changed since stable was released) and an upload must be done for
both stable and unstable of 1.0-2, then the stable upload must be
1.0-1.90 and unstable must be 1.0-2. This is similar to an NMU. The
reason for the .90 is similar in spirit to how glibc starts a
pre-release series (IOW, pre-releases for 2.2 start at 2.1.90).


Caveats:

This policy in no way forces compiled for unstable to be against the
unstable dist. IOW, uploading to unstable does not mean it was compiled
against unstable. That is a little harder to enforce. Perhaps we need a
way to tell dinstall that certain deps are obsoleted for a dist (IOW,
tell dinstall that packages targeted for unstable cannot dep on
libncurses4). However, that is another proposal altogether, and is not
the aim of this one.

--=20
 -----------=3D=3D=3D=3D=3D=3D=3D-=3D-=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=
=3D=3D=3D-----------=3D=3D=3D=3D=3D------------=3D-=3D------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=3D=3D=3D=3D=3D=3D=3D=3D=3D------=3D=3D=3D=3D=3D=3D=3D-------------=3D=
-=3D-----=3D-=3D=3D=3D-=3D=3D=3D=3D=3D=3D-------=3D--=3D---'

--fUYQa+Pmc3FrFX/N
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Ben Collins <bcollins@debian.org>

iD8DBQE6uCiqfNc/ZB4E7C0RAqXwAJ497nIUFnhGOwZYk4IP+5Zs80kUnACfWhlk
E021fm/qqHcgPmRQP+Uk/MQ=
=eV4C
-----END PGP SIGNATURE-----

--fUYQa+Pmc3FrFX/N--




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] disallow multi-distribution uploads
Reply-To: Branden Robinson <branden@debian.org>, 90511@bugs.debian.org
Resent-From: Branden Robinson <branden@debian.org>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 05:33:21 GMT
Resent-Message-ID: <handler.90511.B90511.985151943361@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.985151943361
          (code B ref 90511); Wed, 21 Mar 2001 05:33:21 GMT
Date: Wed, 21 Mar 2001 00:19:02 -0500
From: Branden Robinson <branden@debian.org>
To: 90511@bugs.debian.org
Message-ID: <20010321001902.B16878@deadbeast.net>
References: <20010320230602.X28602@visi.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010320230602.X28602@visi.net>; from bcollins@debian.org on Tue, Mar 20, 2001 at 11:06:02PM -0500
Mail-Copies-To: nobody
X-No-CC: I subscribe to this list; do not CC me on replies.
Delivered-To: 90511@bugs.debian.org


--JP+T4n/bALQSJXh8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 20, 2001 at 11:06:02PM -0500, Ben Collins wrote:
> Summary:
> History:
> Technical reasoning:
> Issues:
> Caveats:

But nowhere did you have the actual text of a policy change.  This is
needed.

Please write one up and I'll second it.

--=20
G. Branden Robinson             |     If a man ate a pound of pasta and a
Debian GNU/Linux                |     pound of antipasto, would they cancel
branden@debian.org              |     out, leaving him still hungry?
http://www.debian.org/~branden/ |     -- Scott Adams

--JP+T4n/bALQSJXh8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjq4OcYACgkQ6kxmHytGonyLEACfbpGTwP8TrGHV3mUUHdd51+Ih
CpcAnR3oLUQmzmeSn6ohKQRWOHgH7edf
=oSxP
-----END PGP SIGNATURE-----

--JP+T4n/bALQSJXh8--




<strong>Acknowledgement sent</strong> to <code>Branden Robinson &lt;branden@debian.org&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Branden Robinson <branden@debian.org>
Subject: Bug#90511: Info received (was Bug#90511: [proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B90511.985151943361.ackinfo@bugs.debian.org>
In-Reply-To: <20010321001902.B16878@deadbeast.net>
References: <20010321001902.B16878@deadbeast.net>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 05:19:03 +0000
From branden@deadbeast.net Tue Mar 20 23:19:03 2001
Return-path: <branden@deadbeast.net>
Received: from cc551902-b.indnpls1.in.home.com (apocalypse.deadbeast.net) [24.183.211.35] (postfix)
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fb1T-00005m-00; Tue, 20 Mar 2001 23:19:03 -0600
Received: by apocalypse.deadbeast.net (Postfix, from userid 1000)
	id 64DF767002; Wed, 21 Mar 2001 00:19:02 -0500 (EST)
Date: Wed, 21 Mar 2001 00:19:02 -0500
From: Branden Robinson <branden@debian.org>
To: 90511@bugs.debian.org
Subject: Re: Bug#90511: [proposal] disallow multi-distribution uploads
Message-ID: <20010321001902.B16878@deadbeast.net>
References: <20010320230602.X28602@visi.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="JP+T4n/bALQSJXh8"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010320230602.X28602@visi.net>; from bcollins@debian.org on Tue, Mar 20, 2001 at 11:06:02PM -0500
Mail-Copies-To: nobody
X-No-CC: I subscribe to this list; do not CC me on replies.
Delivered-To: 90511@bugs.debian.org


--JP+T4n/bALQSJXh8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 20, 2001 at 11:06:02PM -0500, Ben Collins wrote:
> Summary:
> History:
> Technical reasoning:
> Issues:
> Caveats:

But nowhere did you have the actual text of a policy change.  This is
needed.

Please write one up and I'll second it.

--=20
G. Branden Robinson             |     If a man ate a pound of pasta and a
Debian GNU/Linux                |     pound of antipasto, would they cancel
branden@debian.org              |     out, leaving him still hungry?
http://www.debian.org/~branden/ |     -- Scott Adams

--JP+T4n/bALQSJXh8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjq4OcYACgkQ6kxmHytGonyLEACfbpGTwP8TrGHV3mUUHdd51+Ih
CpcAnR3oLUQmzmeSn6ohKQRWOHgH7edf
=oSxP
-----END PGP SIGNATURE-----

--JP+T4n/bALQSJXh8--




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] disallow multi-distribution uploads
Reply-To: Herbert Xu <herbert@gondor.apana.org.au>, 90511@bugs.debian.org
Resent-From: Herbert Xu <herbert@gondor.apana.org.au>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 08:49:15 GMT
Resent-Message-ID: <handler.90511.B90511.98516390126045@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.98516390126045
          (code B ref 90511); Wed, 21 Mar 2001 08:49:15 GMT
Date: Wed, 21 Mar 2001 19:38:08 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
Message-Id: <200103210838.f2L8c8016922@gondor.apana.org.au>
To: 90511@bugs.debian.org
X-Newsgroups: greathan.lists.debian.bugs.dist,greathan.lists.debian.policy
In-Reply-To: <20010320230602.X28602@visi.net>
Organization: Core
User-Agent: tin/pre-1.4-980226 (UNIX) (Linux/2.4.2-586tsc (i586))
Delivered-To: 90511@bugs.debian.org

Ben Collins <bcollins@debian.org> wrote:

> Running a buildd, I have the problem of builds that come in for stable
> and unstable. Currently this means the buildd performs the compile on
> stable, and either uploads to "stable unstable", or as it were

Is there a reason why this option won't work?

> It's my opinion that same version uploads to stable/unstable are harful
> to archive and distribution integrity. I've talked this over with James
> Troup, and he seems to agree with the points below, and is considering
> enforcing them via dinstall checks. My intention is to get the weight
> of policy behind this.

I disagree.  Allowing uploads to both stable and unstable reduces maintainer
load, so that they can spend their precious time doing useful work rather
than needlessly recompiling things.

> Technical reasoning:

> 1) Building for "stable unstable" means that 99% of the time the build
> is performed on a box running "stable". So the package will be compiled
> against "stable" libraries. Now we all know that most of the major
> libraries will go on to new major versions between releases. Ncurses (4
> to 5 between slink and potato), readline (2 to 4 between slink and
> potato), gnome (several revisions during potato development, and others
> now), libstdc++ (which changes with the libc6 major upgrades), etc...

> Now, a lot of libraries keep an oldlib around for backward compatibility
> of packages that have not been recompiled for the newest version of the
> lib. This is a less than optimal situation since it must be maintained
> just like any other package. If libncurses4 is in stable, and
> libncurses5 is in unstable (with the 4 version around only for backward
> compat), then builds in unstable should be using the libncurses5.
> However, someone compiling for "stable unstable" uneedingly prolongs
> this oldlib's life.

But you need to keep old libraries around anyway for compatibility with
other Linux distributions.  We're not the only Linux distribution here.

In fact, having some unstable packages compiled on stable is a
Good Thing (TM).  It means that we actually test whether our libraries
are lying when they claim to have kept their ABI intact (glibc would be
a prime example).  You won't be able to do this if everybody compiled their
unstable packages against unstable.

Of course, if a package doesn't compile on unstable, that would be a
different matter, and a severity serious bug.

> 2) Policy changes. This is probably the worst case. We all know that
> policy abiding build-helpers change between releases just like policy
> does. Take the usr/doc->usr/share/doc changeover scripts, and the X
> default scripts used and hardcoded during the build. Building on stable
> and unstable produces 2 different packages, abiding by two different
> policies.

This is a separate issue.  If there's no way to build a package such that
it complies with both sets of policies, then it shouldn't be built for both
distributions.  Indeed, you can already file serious bugs against such
packages armed with our current policy.

> 3) Build failures. It is commonly the case that a package built on
> stable will not compile on unstable, even though it works runtime wise.

That is a problem, but I don't think it is serious enough to warrant the
prohibition of multi-distribution uploads.

> Issues:

> The only issue I forsee is the likely even of where an upload to stable
> and unstable is desired. I suggest that policy specify this to be done:

> If package "blah" is in stable/unstable of version 1.0-1 (meaning it has
> not changed since stable was released) and an upload must be done for
> both stable and unstable of 1.0-2, then the stable upload must be
> 1.0-1.90 and unstable must be 1.0-2. This is similar to an NMU. The
> reason for the .90 is similar in spirit to how glibc starts a
> pre-release series (IOW, pre-releases for 2.2 start at 2.1.90).

If the package in question cannot be uploaded to both stable and unstable
for reasons such as policy disparity, library compatibility, then yes this
is what should be done.  But that's what we've been doing anyway.  Except
of course that the version number is 1.0-1potato.1 (replace potato with the
name of the current stable distribution).  Otherwise, IMHO this just wastes
the time of the maintainers involved.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt




<strong>Acknowledgement sent</strong> to <code>Herbert Xu &lt;herbert@gondor.apana.org.au&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Herbert Xu <herbert@gondor.apana.org.au>
Subject: Bug#90511: Info received (was Bug#90511: [proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B90511.98516390126045.ackinfo@bugs.debian.org>
In-Reply-To: <200103210838.f2L8c8016922@gondor.apana.org.au>
References: <200103210838.f2L8c8016922@gondor.apana.org.au>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 08:38:21 +0000
From herbert@gondor.apana.org.au Wed Mar 21 02:38:21 2001
Return-path: <herbert@gondor.apana.org.au>
Received: from gondor.apana.org.au [203.14.152.114] (root)
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fe8H-0006l4-00; Wed, 21 Mar 2001 02:38:18 -0600
Received: (from herbert@localhost)
	by gondor.apana.org.au (8.11.1/8.11.1/Debian 8.11.0-6) id f2L8c8016922;
	Wed, 21 Mar 2001 19:38:08 +1100
Date: Wed, 21 Mar 2001 19:38:08 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
Message-Id: <200103210838.f2L8c8016922@gondor.apana.org.au>
To: 90511@bugs.debian.org
Subject: Re: Bug#90511: [proposal] disallow multi-distribution uploads
X-Newsgroups: greathan.lists.debian.bugs.dist,greathan.lists.debian.policy
In-Reply-To: <20010320230602.X28602@visi.net>
Organization: Core
User-Agent: tin/pre-1.4-980226 (UNIX) (Linux/2.4.2-586tsc (i586))
Delivered-To: 90511@bugs.debian.org

Ben Collins <bcollins@debian.org> wrote:

> Running a buildd, I have the problem of builds that come in for stable
> and unstable. Currently this means the buildd performs the compile on
> stable, and either uploads to "stable unstable", or as it were

Is there a reason why this option won't work?

> It's my opinion that same version uploads to stable/unstable are harful
> to archive and distribution integrity. I've talked this over with James
> Troup, and he seems to agree with the points below, and is considering
> enforcing them via dinstall checks. My intention is to get the weight
> of policy behind this.

I disagree.  Allowing uploads to both stable and unstable reduces maintainer
load, so that they can spend their precious time doing useful work rather
than needlessly recompiling things.

> Technical reasoning:

> 1) Building for "stable unstable" means that 99% of the time the build
> is performed on a box running "stable". So the package will be compiled
> against "stable" libraries. Now we all know that most of the major
> libraries will go on to new major versions between releases. Ncurses (4
> to 5 between slink and potato), readline (2 to 4 between slink and
> potato), gnome (several revisions during potato development, and others
> now), libstdc++ (which changes with the libc6 major upgrades), etc...

> Now, a lot of libraries keep an oldlib around for backward compatibility
> of packages that have not been recompiled for the newest version of the
> lib. This is a less than optimal situation since it must be maintained
> just like any other package. If libncurses4 is in stable, and
> libncurses5 is in unstable (with the 4 version around only for backward
> compat), then builds in unstable should be using the libncurses5.
> However, someone compiling for "stable unstable" uneedingly prolongs
> this oldlib's life.

But you need to keep old libraries around anyway for compatibility with
other Linux distributions.  We're not the only Linux distribution here.

In fact, having some unstable packages compiled on stable is a
Good Thing (TM).  It means that we actually test whether our libraries
are lying when they claim to have kept their ABI intact (glibc would be
a prime example).  You won't be able to do this if everybody compiled their
unstable packages against unstable.

Of course, if a package doesn't compile on unstable, that would be a
different matter, and a severity serious bug.

> 2) Policy changes. This is probably the worst case. We all know that
> policy abiding build-helpers change between releases just like policy
> does. Take the usr/doc->usr/share/doc changeover scripts, and the X
> default scripts used and hardcoded during the build. Building on stable
> and unstable produces 2 different packages, abiding by two different
> policies.

This is a separate issue.  If there's no way to build a package such that
it complies with both sets of policies, then it shouldn't be built for both
distributions.  Indeed, you can already file serious bugs against such
packages armed with our current policy.

> 3) Build failures. It is commonly the case that a package built on
> stable will not compile on unstable, even though it works runtime wise.

That is a problem, but I don't think it is serious enough to warrant the
prohibition of multi-distribution uploads.

> Issues:

> The only issue I forsee is the likely even of where an upload to stable
> and unstable is desired. I suggest that policy specify this to be done:

> If package "blah" is in stable/unstable of version 1.0-1 (meaning it has
> not changed since stable was released) and an upload must be done for
> both stable and unstable of 1.0-2, then the stable upload must be
> 1.0-1.90 and unstable must be 1.0-2. This is similar to an NMU. The
> reason for the .90 is similar in spirit to how glibc starts a
> pre-release series (IOW, pre-releases for 2.2 start at 2.1.90).

If the package in question cannot be uploaded to both stable and unstable
for reasons such as policy disparity, library compatibility, then yes this
is what should be done.  But that's what we've been doing anyway.  Except
of course that the version number is 1.0-1potato.1 (replace potato with the
name of the current stable distribution).  Otherwise, IMHO this just wastes
the time of the maintainers involved.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] disallow multi-distribution uploads
Reply-To: Santiago Vila <sanvila@unex.es>, 90511@bugs.debian.org
Resent-From: Santiago Vila <sanvila@unex.es>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 09:09:24 GMT
Resent-Message-ID: <handler.90511.B90511.9851654872170@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.9851654872170
          (code B ref 90511); Wed, 21 Mar 2001 09:09:24 GMT
Date: Wed, 21 Mar 2001 10:03:02 +0100 (CET)
From: Santiago Vila <sanvila@unex.es>
To: <90511@bugs.debian.org>
In-Reply-To: <20010320230602.X28602@visi.net>
Message-ID: <Pine.LNX.4.33.0103210939260.5940-100000@home.unex.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Delivered-To: 90511@bugs.debian.org

On Tue, 20 Mar 2001, Ben Collins wrote:

> Package: debian-policy
>
> Summary:
>
> Policy should disallow uploads for multiple distributions. Specifically
> this means same version uploads to "stable unstable".

Summary: I object.

> [...]
> Technical reasoning:
>
> 1) Building for "stable unstable" means that 99% of the time the build
> is performed on a box running "stable". So the package will be compiled
> against "stable" libraries. Now we all know that most of the major
> libraries will go on to new major versions between releases. Ncurses (4
> to 5 between slink and potato), readline (2 to 4 between slink and
> potato), gnome (several revisions during potato development, and others
> now), libstdc++ (which changes with the libc6 major upgrades), etc...
>
> Now, a lot of libraries keep an oldlib around for backward compatibility
> of packages that have not been recompiled for the newest version of the
> lib. This is a less than optimal situation since it must be maintained
> just like any other package. If libncurses4 is in stable, and
> libncurses5 is in unstable (with the 4 version around only for backward
> compat), then builds in unstable should be using the libncurses5.
> However, someone compiling for "stable unstable" uneedingly prolongs
> this oldlib's life.

This is a good reason to forbid uploads to unstable needing an oldlibs
library (make a policy proposal for that and I'll probably second it)
but not to forbid every upload to "stable unstable".

Uploads which do not use unstable oldlibs libraries are legitimate and
should be allowed.

> 2) Policy changes. This is probably the worst case. We all know that
> policy abiding build-helpers change between releases just like policy
> does. Take the usr/doc->usr/share/doc changeover scripts, and the X
> default scripts used and hardcoded during the build. Building on stable
> and unstable produces 2 different packages, abiding by two different
> policies.
>
> So by allowing stable built apps into unstable, we prolong policy
> changes for the distributions aswell.

Uploads to unstable have to follow latest policy (this is already
policy, isn't it?). If you can't satisfy simultaneously policy on
stable and unstable, it follows that you need different uploads.

Uploads which meet the policy requirements for both stable and unstable
are legitimate and should be allowed.

> 3) Build failures. It is commonly the case that a package built on
> stable will not compile on unstable, even though it works runtime wise.

Make policy that packages uploaded to unstable compile on unstable then,
if it is not already policy.

Uploads to "stable unstable" which compiles fine in both stable and unstable
are legitimate and should be allowed.

I object to this proposal, because it tries to solve common problems
the wrong way, gratuitously forcing people who do not have those
problems to do things differently.

Thanks.





<strong>Acknowledgement sent</strong> to <code>Santiago Vila &lt;sanvila@unex.es&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Santiago Vila <sanvila@unex.es>
Subject: Bug#90511: Info received (was Bug#90511: [proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B90511.9851654872170.ackinfo@bugs.debian.org>
In-Reply-To: <Pine.LNX.4.33.0103210939260.5940-100000@home.unex.es>
References: <Pine.LNX.4.33.0103210939260.5940-100000@home.unex.es>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 09:04:47 +0000
From sanvila@unex.es Wed Mar 21 03:04:47 2001
Return-path: <sanvila@unex.es>
Received: from (smtp.wanadoo.es) [62.36.220.63] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14feXv-0000W3-00; Wed, 21 Mar 2001 03:04:47 -0600
Received: from home.unex.es (62-36-114-169.dialup.uni2.es [62.36.114.169])
	by smtp.wanadoo.es (8.10.2/8.10.2) with ESMTP id f2L94Di07287
	for <90511@bugs.debian.org>; Wed, 21 Mar 2001 10:04:13 +0100 (MET)
Received: from localhost ([127.0.0.1])
	by home.unex.es with esmtp (Exim 3.12 #1 (Debian))
	id 14feWE-0001YR-00
	for <90511@bugs.debian.org>; Wed, 21 Mar 2001 10:03:02 +0100
Date: Wed, 21 Mar 2001 10:03:02 +0100 (CET)
From: Santiago Vila <sanvila@unex.es>
To: <90511@bugs.debian.org>
Subject: Re: Bug#90511: [proposal] disallow multi-distribution uploads
In-Reply-To: <20010320230602.X28602@visi.net>
Message-ID: <Pine.LNX.4.33.0103210939260.5940-100000@home.unex.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Delivered-To: 90511@bugs.debian.org

On Tue, 20 Mar 2001, Ben Collins wrote:

> Package: debian-policy
>
> Summary:
>
> Policy should disallow uploads for multiple distributions. Specifically
> this means same version uploads to "stable unstable".

Summary: I object.

> [...]
> Technical reasoning:
>
> 1) Building for "stable unstable" means that 99% of the time the build
> is performed on a box running "stable". So the package will be compiled
> against "stable" libraries. Now we all know that most of the major
> libraries will go on to new major versions between releases. Ncurses (4
> to 5 between slink and potato), readline (2 to 4 between slink and
> potato), gnome (several revisions during potato development, and others
> now), libstdc++ (which changes with the libc6 major upgrades), etc...
>
> Now, a lot of libraries keep an oldlib around for backward compatibility
> of packages that have not been recompiled for the newest version of the
> lib. This is a less than optimal situation since it must be maintained
> just like any other package. If libncurses4 is in stable, and
> libncurses5 is in unstable (with the 4 version around only for backward
> compat), then builds in unstable should be using the libncurses5.
> However, someone compiling for "stable unstable" uneedingly prolongs
> this oldlib's life.

This is a good reason to forbid uploads to unstable needing an oldlibs
library (make a policy proposal for that and I'll probably second it)
but not to forbid every upload to "stable unstable".

Uploads which do not use unstable oldlibs libraries are legitimate and
should be allowed.

> 2) Policy changes. This is probably the worst case. We all know that
> policy abiding build-helpers change between releases just like policy
> does. Take the usr/doc->usr/share/doc changeover scripts, and the X
> default scripts used and hardcoded during the build. Building on stable
> and unstable produces 2 different packages, abiding by two different
> policies.
>
> So by allowing stable built apps into unstable, we prolong policy
> changes for the distributions aswell.

Uploads to unstable have to follow latest policy (this is already
policy, isn't it?). If you can't satisfy simultaneously policy on
stable and unstable, it follows that you need different uploads.

Uploads which meet the policy requirements for both stable and unstable
are legitimate and should be allowed.

> 3) Build failures. It is commonly the case that a package built on
> stable will not compile on unstable, even though it works runtime wise.

Make policy that packages uploaded to unstable compile on unstable then,
if it is not already policy.

Uploads to "stable unstable" which compiles fine in both stable and unstable
are legitimate and should be allowed.

I object to this proposal, because it tries to solve common problems
the wrong way, gratuitously forcing people who do not have those
problems to do things differently.

Thanks.





<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] disallow multi-distribution uploads
Reply-To: Ben Collins <bcollins@debian.org>, 90511@bugs.debian.org
Resent-From: Ben Collins <bcollins@debian.org>
Orignal-Sender: Ben Collins <bmc@visi.net>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 15:48:22 GMT
Resent-Message-ID: <handler.90511.B90511.9851891005496@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.9851891005496
          (code B ref 90511); Wed, 21 Mar 2001 15:48:22 GMT
Date: Wed, 21 Mar 2001 10:37:56 -0500
From: Ben Collins <bcollins@debian.org>
To: Herbert Xu <herbert@gondor.apana.org.au>, 90511@bugs.debian.org
Message-ID: <20010321103756.U28602@visi.net>
References: <20010320230602.X28602@visi.net> <200103210838.f2L8c8016922@gondor.apana.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <200103210838.f2L8c8016922@gondor.apana.org.au>; from herbert@gondor.apana.org.au on Wed, Mar 21, 2001 at 07:38:08PM +1100
Sender: Ben Collins <bmc@visi.net>
Delivered-To: 90511@bugs.debian.org

Remember that the majority of uploads to stable are done by the security
team and the buildd's. I don't think this is a lot of effort for the
maintainers, since it isn't done often enough to be cumbersome, like it
would have been for "frozen unstable" uploads.

On Wed, Mar 21, 2001 at 07:38:08PM +1100, Herbert Xu wrote:
> > It's my opinion that same version uploads to stable/unstable are harful
> > to archive and distribution integrity. I've talked this over with James
> > Troup, and he seems to agree with the points below, and is considering
> > enforcing them via dinstall checks. My intention is to get the weight
> > of policy behind this.
> 
> I disagree.  Allowing uploads to both stable and unstable reduces maintainer
> load, so that they can spend their precious time doing useful work rather
> than needlessly recompiling things.

Think of a base system. If things are allowed to continue this way, it
means the base system will be comprised of a lot of different versions
of the same library. That makes a base install larger

> > Technical reasoning:
> 
> > 1) Building for "stable unstable" means that 99% of the time the build
> > is performed on a box running "stable". So the package will be compiled
> > against "stable" libraries. Now we all know that most of the major
> > libraries will go on to new major versions between releases. Ncurses (4
> > to 5 between slink and potato), readline (2 to 4 between slink and
> > potato), gnome (several revisions during potato development, and others
> > now), libstdc++ (which changes with the libc6 major upgrades), etc...
> 
> > Now, a lot of libraries keep an oldlib around for backward compatibility
> > of packages that have not been recompiled for the newest version of the
> > lib. This is a less than optimal situation since it must be maintained
> > just like any other package. If libncurses4 is in stable, and
> > libncurses5 is in unstable (with the 4 version around only for backward
> > compat), then builds in unstable should be using the libncurses5.
> > However, someone compiling for "stable unstable" uneedingly prolongs
> > this oldlib's life.
> 
> But you need to keep old libraries around anyway for compatibility with
> other Linux distributions.  We're not the only Linux distribution here.
> 
> In fact, having some unstable packages compiled on stable is a
> Good Thing (TM).  It means that we actually test whether our libraries
> are lying when they claim to have kept their ABI intact (glibc would be
> a prime example).  You won't be able to do this if everybody compiled their
> unstable packages against unstable.
> 
> Of course, if a package doesn't compile on unstable, that would be a
> different matter, and a severity serious bug.

This isn't about keeping old libraries around. For one, people can
always get it from the old dist, or they will just keep it installed and
not remove it. This is about the libraries required by Debian packages
themselves. New uploads should always strive to be built agains the
latest packages, to reduce the dependency chain in the dist, and
increase integrity of the compile base.


-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'




<strong>Acknowledgement sent</strong> to <code>Ben Collins &lt;bcollins@debian.org&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Ben Collins <bcollins@debian.org>
Subject: Bug#90511: Info received (was Bug#90511: proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B90511.9851891005496.ackinfo@bugs.debian.org>
In-Reply-To: <20010321103756.U28602@visi.net>
References: <20010321103756.U28602@visi.net>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 15:38:20 +0000
From bmc@visi.net Wed Mar 21 09:38:20 2001
Return-path: <bmc@visi.net>
Received: from ppp28.ts2-2.newportnews.visi.net (blimpo.internal.net) [209.8.198.28] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fkgl-0001QZ-00; Wed, 21 Mar 2001 09:38:20 -0600
Received: from bmc by blimpo.internal.net with local (Exim 3.22 #1 (Debian))
	id 14fkgO-0001dX-00; Wed, 21 Mar 2001 10:37:56 -0500
Date: Wed, 21 Mar 2001 10:37:56 -0500
From: Ben Collins <bcollins@debian.org>
To: Herbert Xu <herbert@gondor.apana.org.au>, 90511@bugs.debian.org
Subject: Re: Bug#90511: proposal] disallow multi-distribution uploads
Message-ID: <20010321103756.U28602@visi.net>
References: <20010320230602.X28602@visi.net> <200103210838.f2L8c8016922@gondor.apana.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <200103210838.f2L8c8016922@gondor.apana.org.au>; from herbert@gondor.apana.org.au on Wed, Mar 21, 2001 at 07:38:08PM +1100
Sender: Ben Collins <bmc@visi.net>
Delivered-To: 90511@bugs.debian.org

Remember that the majority of uploads to stable are done by the security
team and the buildd's. I don't think this is a lot of effort for the
maintainers, since it isn't done often enough to be cumbersome, like it
would have been for "frozen unstable" uploads.

On Wed, Mar 21, 2001 at 07:38:08PM +1100, Herbert Xu wrote:
> > It's my opinion that same version uploads to stable/unstable are harful
> > to archive and distribution integrity. I've talked this over with James
> > Troup, and he seems to agree with the points below, and is considering
> > enforcing them via dinstall checks. My intention is to get the weight
> > of policy behind this.
> 
> I disagree.  Allowing uploads to both stable and unstable reduces maintainer
> load, so that they can spend their precious time doing useful work rather
> than needlessly recompiling things.

Think of a base system. If things are allowed to continue this way, it
means the base system will be comprised of a lot of different versions
of the same library. That makes a base install larger

> > Technical reasoning:
> 
> > 1) Building for "stable unstable" means that 99% of the time the build
> > is performed on a box running "stable". So the package will be compiled
> > against "stable" libraries. Now we all know that most of the major
> > libraries will go on to new major versions between releases. Ncurses (4
> > to 5 between slink and potato), readline (2 to 4 between slink and
> > potato), gnome (several revisions during potato development, and others
> > now), libstdc++ (which changes with the libc6 major upgrades), etc...
> 
> > Now, a lot of libraries keep an oldlib around for backward compatibility
> > of packages that have not been recompiled for the newest version of the
> > lib. This is a less than optimal situation since it must be maintained
> > just like any other package. If libncurses4 is in stable, and
> > libncurses5 is in unstable (with the 4 version around only for backward
> > compat), then builds in unstable should be using the libncurses5.
> > However, someone compiling for "stable unstable" uneedingly prolongs
> > this oldlib's life.
> 
> But you need to keep old libraries around anyway for compatibility with
> other Linux distributions.  We're not the only Linux distribution here.
> 
> In fact, having some unstable packages compiled on stable is a
> Good Thing (TM).  It means that we actually test whether our libraries
> are lying when they claim to have kept their ABI intact (glibc would be
> a prime example).  You won't be able to do this if everybody compiled their
> unstable packages against unstable.
> 
> Of course, if a package doesn't compile on unstable, that would be a
> different matter, and a severity serious bug.

This isn't about keeping old libraries around. For one, people can
always get it from the old dist, or they will just keep it installed and
not remove it. This is about the libraries required by Debian packages
themselves. New uploads should always strive to be built agains the
latest packages, to reduce the dependency chain in the dist, and
increase integrity of the compile base.


-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] disallow multi-distribution uploads
Reply-To: Ben Collins <bcollins@debian.org>, 90511@bugs.debian.org
Resent-From: Ben Collins <bcollins@debian.org>
Orignal-Sender: Ben Collins <bmc@visi.net>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 17:48:09 GMT
Resent-Message-ID: <handler.90511.B90511.98519673624996@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.98519673624996
          (code B ref 90511); Wed, 21 Mar 2001 17:48:09 GMT
Date: Wed, 21 Mar 2001 12:45:31 -0500
From: Ben Collins <bcollins@debian.org>
To: Branden Robinson <branden@debian.org>, 90511@bugs.debian.org
Message-ID: <20010321124531.A28602@visi.net>
References: <20010320230602.X28602@visi.net> <20010321001902.B16878@deadbeast.net>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="V0207lvV8h4k8FAm"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321001902.B16878@deadbeast.net>; from branden@debian.org on Wed, Mar 21, 2001 at 12:19:02AM -0500
Sender: Ben Collins <bmc@visi.net>
Delivered-To: 90511@bugs.debian.org


--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Mar 21, 2001 at 12:19:02AM -0500, Branden Robinson wrote:
> On Tue, Mar 20, 2001 at 11:06:02PM -0500, Ben Collins wrote:
> > Summary:
> > History:
> > Technical reasoning:
> > Issues:
> > Caveats:
> 
> But nowhere did you have the actual text of a policy change.  This is
> needed.
> 
> Please write one up and I'll second it.

Right, here it is.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="policy.diff"

diff -urN debian-policy-3.5.2.0.orig/policy.sgml debian-policy-3.5.2.0/policy.sgml
--- debian-policy-3.5.2.0.orig/policy.sgml	Sun Feb 18 09:37:35 2001
+++ debian-policy-3.5.2.0/policy.sgml	Wed Mar 21 12:44:48 2001
@@ -1400,8 +1400,8 @@
 
 	  <p>
 	    In a <tt>.changes</tt> file or parsed changelog output
-	    this contains the (space-separated) name(s) of the
-	    distribution(s) where this version of the package should
+	    this contains the name of the
+	    distribution where this version of the package should
 	    be or was installed.  Distribution names follow the rules
 	    for package names.  (See <ref id="f-Package">).
 	  </p>
@@ -1434,15 +1434,23 @@
 		    </p>
 		  </item>
 
-		  <tag><em>frozen</em></tag>
+		  <tag><em>testing</em></tag>
 		  <item>
 		    <p>
-		      From time to time, the <em>unstable</em>
-		      distribution enters a state of `code-freeze' in
-		      anticipation of release as a <em>stable</em>
-		      version. During this period of testing only
-		      fixes for existing or newly-discovered bugs will
-		      be allowed.
+		      Testing is a psuedo distribution that is a
+		      culmination of the previous <em>stable</em> release
+		      with select packages from <em>unstable</em> applied
+		      to it. The packages have to meet certain criteria in
+		      order to migrate from <em>unstable</em> into
+		      <em>testing</em>. Some of these criteria include being
+		      compiled on all supported architectures, no open
+		      release critical bugs and no dependencies on
+		      packages that are not in <em>testing</em> already
+		      (which may fail some of these criteria). Also, there
+		      is a time constraint before migration. Note, you cannot
+		      upload directly to <em>testing</em> as you can with
+		      <em>stable</em> and <em>unstable</em>. This distribution
+		      is the base for the next planned release.
 		    </p>
 		  </item>
 
@@ -1493,12 +1501,26 @@
 		      Distribution.</p>
 		  </item>
 
-		</taglist> You should list <em>all</em> distributions that
-		the package should be installed into. Except in unusual
-		circumstances, installations to <em>stable</em> should also
-		go into <em>frozen</em> (if it exists) and
-		<em>unstable</em>. Likewise, installations into
-		<em>frozen</em> should also go into <em>unstable</em>.
+		</taglist>
+		You should list <em>only</em> the distribution that the
+		package was compiled for. Do not upload to multiple
+		distributions. Currently it is only possible to upload to
+		<em>stable</em>, <em>unstable</em> or <em>experimental</em>.
+		If an upload needs to go to both <em>stable</em> and
+		<em>unstable</em>, then they must be uploaded seperately,
+		and with different version numbers, the <em>stable</em>
+		version being less than the <em>unstable</em> one.
+		<p>
+		One example of this is if the current version of the
+		<em>stable</em> and <em>unstable</em> package is 1.2-1, then
+		a new upload can have 1.2-1.90 for <em>stable</em> and 1.2-2 for
+		<em>unstable</em>. Each should be compiled on that
+		particular distribution, so that it abides by the policy
+		of that distribution, so it will use the latest libraries
+		available on that distribution, and so it will be in sync with
+		what the autobuilders for the other architectures produce (they
+		always build on the latest version of a particular
+		distribution).
 	    </footnote>
 	  </p>
 	</sect1>
@@ -1997,7 +2019,7 @@
 	<p>
 	  That format is a series of entries like this:
 	  <example>
-	    <var>package</var> (<var>version</var>) <var>distribution(s)</var>; urgency=<var>urgency</var>
+	    <var>package</var> (<var>version</var>) <var>distribution</var>; urgency=<var>urgency</var>
 
 	    * <var>change details</var>
 	    <var>more change details</var>
@@ -2013,7 +2035,7 @@
 	</p>
 
 	<p>
-	  <var>distribution(s)</var> lists the distributions where
+	  <var>distribution</var> lists the distribution where
 	  this version should be installed when it is uploaded - it
 	  is copied to the <tt>Distribution</tt> field in the
 	  <tt>.changes</tt> file.  See <ref id="f-Distribution">.

--V0207lvV8h4k8FAm--




<strong>Acknowledgement sent</strong> to <code>Ben Collins &lt;bcollins@debian.org&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Ben Collins <bcollins@debian.org>
Subject: Bug#90511: Info received (was Bug#90511: proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B90511.98519673624996.ackinfo@bugs.debian.org>
In-Reply-To: <20010321124531.A28602@visi.net>
References: <20010321124531.A28602@visi.net>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 17:45:36 +0000
From bmc@visi.net Wed Mar 21 11:45:36 2001
Return-path: <bmc@visi.net>
Received: from ppp33.ts6-2.newportnews.visi.net (blimpo.internal.net) [209.8.199.33] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fmfu-0006Ur-00; Wed, 21 Mar 2001 11:45:35 -0600
Received: from bmc by blimpo.internal.net with local (Exim 3.22 #1 (Debian))
	id 14fmfr-0002Dy-00; Wed, 21 Mar 2001 12:45:31 -0500
Date: Wed, 21 Mar 2001 12:45:31 -0500
From: Ben Collins <bcollins@debian.org>
To: Branden Robinson <branden@debian.org>, 90511@bugs.debian.org
Subject: Re: Bug#90511: proposal] disallow multi-distribution uploads
Message-ID: <20010321124531.A28602@visi.net>
References: <20010320230602.X28602@visi.net> <20010321001902.B16878@deadbeast.net>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="V0207lvV8h4k8FAm"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321001902.B16878@deadbeast.net>; from branden@debian.org on Wed, Mar 21, 2001 at 12:19:02AM -0500
Sender: Ben Collins <bmc@visi.net>
Delivered-To: 90511@bugs.debian.org


--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Mar 21, 2001 at 12:19:02AM -0500, Branden Robinson wrote:
> On Tue, Mar 20, 2001 at 11:06:02PM -0500, Ben Collins wrote:
> > Summary:
> > History:
> > Technical reasoning:
> > Issues:
> > Caveats:
> 
> But nowhere did you have the actual text of a policy change.  This is
> needed.
> 
> Please write one up and I'll second it.

Right, here it is.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'

--V0207lvV8h4k8FAm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="policy.diff"

diff -urN debian-policy-3.5.2.0.orig/policy.sgml debian-policy-3.5.2.0/policy.sgml
--- debian-policy-3.5.2.0.orig/policy.sgml	Sun Feb 18 09:37:35 2001
+++ debian-policy-3.5.2.0/policy.sgml	Wed Mar 21 12:44:48 2001
@@ -1400,8 +1400,8 @@
 
 	  <p>
 	    In a <tt>.changes</tt> file or parsed changelog output
-	    this contains the (space-separated) name(s) of the
-	    distribution(s) where this version of the package should
+	    this contains the name of the
+	    distribution where this version of the package should
 	    be or was installed.  Distribution names follow the rules
 	    for package names.  (See <ref id="f-Package">).
 	  </p>
@@ -1434,15 +1434,23 @@
 		    </p>
 		  </item>
 
-		  <tag><em>frozen</em></tag>
+		  <tag><em>testing</em></tag>
 		  <item>
 		    <p>
-		      From time to time, the <em>unstable</em>
-		      distribution enters a state of `code-freeze' in
-		      anticipation of release as a <em>stable</em>
-		      version. During this period of testing only
-		      fixes for existing or newly-discovered bugs will
-		      be allowed.
+		      Testing is a psuedo distribution that is a
+		      culmination of the previous <em>stable</em> release
+		      with select packages from <em>unstable</em> applied
+		      to it. The packages have to meet certain criteria in
+		      order to migrate from <em>unstable</em> into
+		      <em>testing</em>. Some of these criteria include being
+		      compiled on all supported architectures, no open
+		      release critical bugs and no dependencies on
+		      packages that are not in <em>testing</em> already
+		      (which may fail some of these criteria). Also, there
+		      is a time constraint before migration. Note, you cannot
+		      upload directly to <em>testing</em> as you can with
+		      <em>stable</em> and <em>unstable</em>. This distribution
+		      is the base for the next planned release.
 		    </p>
 		  </item>
 
@@ -1493,12 +1501,26 @@
 		      Distribution.</p>
 		  </item>
 
-		</taglist> You should list <em>all</em> distributions that
-		the package should be installed into. Except in unusual
-		circumstances, installations to <em>stable</em> should also
-		go into <em>frozen</em> (if it exists) and
-		<em>unstable</em>. Likewise, installations into
-		<em>frozen</em> should also go into <em>unstable</em>.
+		</taglist>
+		You should list <em>only</em> the distribution that the
+		package was compiled for. Do not upload to multiple
+		distributions. Currently it is only possible to upload to
+		<em>stable</em>, <em>unstable</em> or <em>experimental</em>.
+		If an upload needs to go to both <em>stable</em> and
+		<em>unstable</em>, then they must be uploaded seperately,
+		and with different version numbers, the <em>stable</em>
+		version being less than the <em>unstable</em> one.
+		<p>
+		One example of this is if the current version of the
+		<em>stable</em> and <em>unstable</em> package is 1.2-1, then
+		a new upload can have 1.2-1.90 for <em>stable</em> and 1.2-2 for
+		<em>unstable</em>. Each should be compiled on that
+		particular distribution, so that it abides by the policy
+		of that distribution, so it will use the latest libraries
+		available on that distribution, and so it will be in sync with
+		what the autobuilders for the other architectures produce (they
+		always build on the latest version of a particular
+		distribution).
 	    </footnote>
 	  </p>
 	</sect1>
@@ -1997,7 +2019,7 @@
 	<p>
 	  That format is a series of entries like this:
 	  <example>
-	    <var>package</var> (<var>version</var>) <var>distribution(s)</var>; urgency=<var>urgency</var>
+	    <var>package</var> (<var>version</var>) <var>distribution</var>; urgency=<var>urgency</var>
 
 	    * <var>change details</var>
 	    <var>more change details</var>
@@ -2013,7 +2035,7 @@
 	</p>
 
 	<p>
-	  <var>distribution(s)</var> lists the distributions where
+	  <var>distribution</var> lists the distribution where
 	  this version should be installed when it is uploaded - it
 	  is copied to the <tt>Distribution</tt> field in the
 	  <tt>.changes</tt> file.  See <ref id="f-Distribution">.

--V0207lvV8h4k8FAm--




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
Reply-To: Ben Collins <bcollins@debian.org>, 90511@bugs.debian.org
Resent-From: Ben Collins <bcollins@debian.org>
Orignal-Sender: Ben Collins <bmc@visi.net>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 19:05:45 GMT
Resent-Message-ID: <handler.90511.B90511.9851984004052@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.9851984004052
          (code B ref 90511); Wed, 21 Mar 2001 19:05:45 GMT
Date: Wed, 21 Mar 2001 13:13:17 -0500
From: Ben Collins <bcollins@debian.org>
To: 90511@bugs.debian.org
Message-ID: <20010321131316.B28602@visi.net>
References: <20010320230602.X28602@visi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010320230602.X28602@visi.net>; from bcollins@debian.org on Tue, Mar 20, 2001 at 11:06:02PM -0500
Sender: Ben Collins <bmc@visi.net>
Delivered-To: 90511@bugs.debian.org

The only objections I have seen are simplified by "it is too difficult
to for that one maintainers" and "it should be possible to do this for
packages that do not break".

As for the first. Multi distributions occur so infrequently that it
should not be a problem to do this. Most of the time a package is
already diverged between stable and unstable, so two uploads are still
required in that case for security fixes. Enforcing this just means we
have more consistency. Allowing it for convenience makes no technical
sense.

As for allowing them in cases where they don't fall into any of my
listed points of breakage, I ask that you give a solid technical reason
why even those should be allowed, other than simple convienience. I see
no reason for it. In fact, the only technical reason was back when we
had frozen/unstable uploads, and they do not occur any longer.

So, if those objecters will adress my counter-objection to them, I will
concede the objection. The first point is probably too open to opinion
to be a true technical objection. The second I feel requires more than
just an objection, but a solid foundation based on technical reason.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'




<strong>Acknowledgement sent</strong> to <code>Ben Collins &lt;bcollins@debian.org&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Ben Collins <bcollins@debian.org>
Subject: Bug#90511: Info received (was Bug#90511: [proposal] addressing objections (re: disallow multi-distribution uploads))
Message-ID: <handler.90511.B90511.9851984004052.ackinfo@bugs.debian.org>
In-Reply-To: <20010321131316.B28602@visi.net>
References: <20010321131316.B28602@visi.net>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 18:13:20 +0000
From bmc@visi.net Wed Mar 21 12:13:20 2001
Return-path: <bmc@visi.net>
Received: from ppp33.ts6-2.newportnews.visi.net (blimpo.internal.net) [209.8.199.33] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fn6l-000134-00; Wed, 21 Mar 2001 12:13:20 -0600
Received: from bmc by blimpo.internal.net with local (Exim 3.22 #1 (Debian))
	id 14fn6j-0002GA-00
	for <90511@bugs.debian.org>; Wed, 21 Mar 2001 13:13:17 -0500
Date: Wed, 21 Mar 2001 13:13:17 -0500
From: Ben Collins <bcollins@debian.org>
To: 90511@bugs.debian.org
Subject: Re: Bug#90511: [proposal] addressing objections (re: disallow multi-distribution uploads)
Message-ID: <20010321131316.B28602@visi.net>
References: <20010320230602.X28602@visi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010320230602.X28602@visi.net>; from bcollins@debian.org on Tue, Mar 20, 2001 at 11:06:02PM -0500
Sender: Ben Collins <bmc@visi.net>
Delivered-To: 90511@bugs.debian.org

The only objections I have seen are simplified by "it is too difficult
to for that one maintainers" and "it should be possible to do this for
packages that do not break".

As for the first. Multi distributions occur so infrequently that it
should not be a problem to do this. Most of the time a package is
already diverged between stable and unstable, so two uploads are still
required in that case for security fixes. Enforcing this just means we
have more consistency. Allowing it for convenience makes no technical
sense.

As for allowing them in cases where they don't fall into any of my
listed points of breakage, I ask that you give a solid technical reason
why even those should be allowed, other than simple convienience. I see
no reason for it. In fact, the only technical reason was back when we
had frozen/unstable uploads, and they do not occur any longer.

So, if those objecters will adress my counter-objection to them, I will
concede the objection. The first point is probably too open to opinion
to be a true technical objection. The second I feel requires more than
just an objection, but a solid foundation based on technical reason.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] disallow multi-distribution uploads
Reply-To: Branden Robinson <branden@debian.org>, 90511@bugs.debian.org
Resent-From: Branden Robinson <branden@debian.org>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 20:33:16 GMT
Resent-Message-ID: <handler.90511.B90511.98520620923556@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.98520620923556
          (code B ref 90511); Wed, 21 Mar 2001 20:33:16 GMT
Date: Wed, 21 Mar 2001 15:23:29 -0500
From: Branden Robinson <branden@debian.org>
To: 90511@bugs.debian.org
Message-ID: <20010321152329.C17889@deadbeast.net>
References: <20010320230602.X28602@visi.net> <20010321001902.B16878@deadbeast.net> <20010321124531.A28602@visi.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321124531.A28602@visi.net>; from bcollins@debian.org on Wed, Mar 21, 2001 at 12:45:31PM -0500
Mail-Copies-To: nobody
X-No-CC: I subscribe to this list; do not CC me on replies.
Delivered-To: 90511@bugs.debian.org


--jy6Sn24JjFx/iggw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 21, 2001 at 12:45:31PM -0500, Ben Collins wrote:
> diff -urN debian-policy-3.5.2.0.orig/policy.sgml debian-policy-3.5.2.0/po=
licy.sgml
[snip]

Seconded.

--=20
G. Branden Robinson             |    Software engineering: that part of
Debian GNU/Linux                |    computer science which is too difficult
branden@debian.org              |    for the computer scientist.
http://www.debian.org/~branden/ |

--jy6Sn24JjFx/iggw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjq5DcEACgkQ6kxmHytGonyzawCfd3a+aW4cQMQ/LAaR/EmjKjpb
pqMAnja3Q1oKNEZWQL/1u9t1WQ7VjFQe
=+xEy
-----END PGP SIGNATURE-----

--jy6Sn24JjFx/iggw--




<strong>Acknowledgement sent</strong> to <code>Branden Robinson &lt;branden@debian.org&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Branden Robinson <branden@debian.org>
Subject: Bug#90511: Info received (was Bug#90511: proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B90511.98520620923556.ackinfo@bugs.debian.org>
In-Reply-To: <20010321152329.C17889@deadbeast.net>
References: <20010321152329.C17889@deadbeast.net>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 20:23:29 +0000
From branden@deadbeast.net Wed Mar 21 14:23:29 2001
Return-path: <branden@deadbeast.net>
Received: from cc551902-b.indnpls1.in.home.com (apocalypse.deadbeast.net) [24.183.211.35] (postfix)
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fp8j-00067q-00; Wed, 21 Mar 2001 14:23:29 -0600
Received: by apocalypse.deadbeast.net (Postfix, from userid 1000)
	id 69B5A67002; Wed, 21 Mar 2001 15:23:29 -0500 (EST)
Date: Wed, 21 Mar 2001 15:23:29 -0500
From: Branden Robinson <branden@debian.org>
To: 90511@bugs.debian.org
Subject: Re: Bug#90511: proposal] disallow multi-distribution uploads
Message-ID: <20010321152329.C17889@deadbeast.net>
References: <20010320230602.X28602@visi.net> <20010321001902.B16878@deadbeast.net> <20010321124531.A28602@visi.net>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="jy6Sn24JjFx/iggw"
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321124531.A28602@visi.net>; from bcollins@debian.org on Wed, Mar 21, 2001 at 12:45:31PM -0500
Mail-Copies-To: nobody
X-No-CC: I subscribe to this list; do not CC me on replies.
Delivered-To: 90511@bugs.debian.org


--jy6Sn24JjFx/iggw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 21, 2001 at 12:45:31PM -0500, Ben Collins wrote:
> diff -urN debian-policy-3.5.2.0.orig/policy.sgml debian-policy-3.5.2.0/po=
licy.sgml
[snip]

Seconded.

--=20
G. Branden Robinson             |    Software engineering: that part of
Debian GNU/Linux                |    computer science which is too difficult
branden@debian.org              |    for the computer scientist.
http://www.debian.org/~branden/ |

--jy6Sn24JjFx/iggw
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjq5DcEACgkQ6kxmHytGonyzawCfd3a+aW4cQMQ/LAaR/EmjKjpb
pqMAnja3Q1oKNEZWQL/1u9t1WQ7VjFQe
=+xEy
-----END PGP SIGNATURE-----

--jy6Sn24JjFx/iggw--




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] disallow multi-distribution uploads
Reply-To: Herbert Xu <herbert@gondor.apana.org.au>, 90511@bugs.debian.org
Resent-From: Herbert Xu <herbert@gondor.apana.org.au>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 20:33:27 GMT
Resent-Message-ID: <handler.90511.B90511.98520668628137@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.98520668628137
          (code B ref 90511); Wed, 21 Mar 2001 20:33:27 GMT
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Mar 2001 07:31:18 +1100
To: Ben Collins <bcollins@debian.org>
Cc: 90511@bugs.debian.org
Message-ID: <20010322073118.A25574@gondor.apana.org.au>
References: <20010320230602.X28602@visi.net> <200103210838.f2L8c8016922@gondor.apana.org.au> <20010321103756.U28602@visi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321103756.U28602@visi.net>; from bcollins@debian.org on Wed, Mar 21, 2001 at 10:37:56AM -0500
Delivered-To: 90511@bugs.debian.org

On Wed, Mar 21, 2001 at 10:37:56AM -0500, Ben Collins wrote:
> Remember that the majority of uploads to stable are done by the security
> team and the buildd's. I don't think this is a lot of effort for the
> maintainers, since it isn't done often enough to be cumbersome, like it
> would have been for "frozen unstable" uploads.

Well this hasn't been the case in my experience.  Most of the security
problems that has occured in my packages resulted in uploads by myself, not
the security team.

> Think of a base system. If things are allowed to continue this way, it
> means the base system will be comprised of a lot of different versions
> of the same library. That makes a base install larger

This is a different issue.  Besides, you won't solve it by gettint people
to do different uploads since they can compile both on stable (some
developers only run stable machines immediately after a release).  What you
need to here is to file bug reports against packages that compile against
obsolete sonames.

> This isn't about keeping old libraries around. For one, people can
> always get it from the old dist, or they will just keep it installed and
> not remove it. This is about the libraries required by Debian packages
> themselves. New uploads should always strive to be built agains the
> latest packages, to reduce the dependency chain in the dist, and
> increase integrity of the compile base.

But you won't solve the soname problem by doing this since uploading to
unstable doesn't mean that the package was actually compiled on unstable.
Personally bug reports have been just fine in solving this problem.

And as I said in my previous message, for libraries with the soname
(like glibc), you do want to test it against old -dev packages to ensure
binary compatibility.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt




<strong>Acknowledgement sent</strong> to <code>Herbert Xu &lt;herbert@gondor.apana.org.au&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Herbert Xu <herbert@gondor.apana.org.au>
Subject: Bug#90511: Info received (was Bug#90511: proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B90511.98520668628137.ackinfo@bugs.debian.org>
In-Reply-To: <20010322073118.A25574@gondor.apana.org.au>
References: <20010322073118.A25574@gondor.apana.org.au>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 20:31:26 +0000
From herbert@gondor.apana.org.au Wed Mar 21 14:31:26 2001
Return-path: <herbert@gondor.apana.org.au>
Received: from gondor.apana.org.au [203.14.152.114] (root)
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fpGO-0007JM-00; Wed, 21 Mar 2001 14:31:25 -0600
Received: (from herbert@localhost)
	by gondor.apana.org.au (8.11.1/8.11.1/Debian 8.11.0-6) id f2LKVJ625860;
	Thu, 22 Mar 2001 07:31:19 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Mar 2001 07:31:18 +1100
To: Ben Collins <bcollins@debian.org>
Cc: 90511@bugs.debian.org
Subject: Re: Bug#90511: proposal] disallow multi-distribution uploads
Message-ID: <20010322073118.A25574@gondor.apana.org.au>
References: <20010320230602.X28602@visi.net> <200103210838.f2L8c8016922@gondor.apana.org.au> <20010321103756.U28602@visi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321103756.U28602@visi.net>; from bcollins@debian.org on Wed, Mar 21, 2001 at 10:37:56AM -0500
Delivered-To: 90511@bugs.debian.org

On Wed, Mar 21, 2001 at 10:37:56AM -0500, Ben Collins wrote:
> Remember that the majority of uploads to stable are done by the security
> team and the buildd's. I don't think this is a lot of effort for the
> maintainers, since it isn't done often enough to be cumbersome, like it
> would have been for "frozen unstable" uploads.

Well this hasn't been the case in my experience.  Most of the security
problems that has occured in my packages resulted in uploads by myself, not
the security team.

> Think of a base system. If things are allowed to continue this way, it
> means the base system will be comprised of a lot of different versions
> of the same library. That makes a base install larger

This is a different issue.  Besides, you won't solve it by gettint people
to do different uploads since they can compile both on stable (some
developers only run stable machines immediately after a release).  What you
need to here is to file bug reports against packages that compile against
obsolete sonames.

> This isn't about keeping old libraries around. For one, people can
> always get it from the old dist, or they will just keep it installed and
> not remove it. This is about the libraries required by Debian packages
> themselves. New uploads should always strive to be built agains the
> latest packages, to reduce the dependency chain in the dist, and
> increase integrity of the compile base.

But you won't solve the soname problem by doing this since uploading to
unstable doesn't mean that the package was actually compiled on unstable.
Personally bug reports have been just fine in solving this problem.

And as I said in my previous message, for libraries with the soname
(like glibc), you do want to test it against old -dev packages to ensure
binary compatibility.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
Reply-To: Herbert Xu <herbert@gondor.apana.org.au>, 90511@bugs.debian.org
Resent-From: Herbert Xu <herbert@gondor.apana.org.au>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 20:48:04 GMT
Resent-Message-ID: <handler.90511.B90511.9852075422769@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.9852075422769
          (code B ref 90511); Wed, 21 Mar 2001 20:48:04 GMT
Date: Thu, 22 Mar 2001 07:45:27 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
Message-Id: <200103212045.f2LKjRZ26269@gondor.apana.org.au>
To: Ben Collins <bcollins@debian.org>, 90511@bugs.debian.org
X-Newsgroups: greathan.lists.debian.bugs.dist,greathan.lists.debian.policy
In-Reply-To: <20010320230602.X28602@visi.net> <20010321131316.B28602@visi.net>
Organization: Core
User-Agent: tin/pre-1.4-980226 (UNIX) (Linux/2.4.2-586tsc (i586))
Delivered-To: 90511@bugs.debian.org

Ben Collins <bcollins@debian.org> wrote:

> As for the first. Multi distributions occur so infrequently that it
> should not be a problem to do this. Most of the time a package is
> already diverged between stable and unstable, so two uploads are still
> required in that case for security fixes. Enforcing this just means we
> have more consistency. Allowing it for convenience makes no technical
> sense.

Perhaps this has been your experience (understably since you maintain a lot
of library packages that are actively developed).  However, im my
experience, I've certainly done my fair share of "stable unstabe" uploads,
and I do not welcome the prospect of having to double those just to solve
some non-existant problem.

> As for allowing them in cases where they don't fall into any of my
> listed points of breakage, I ask that you give a solid technical reason
> why even those should be allowed, other than simple convienience. I see
> no reason for it. In fact, the only technical reason was back when we
> had frozen/unstable uploads, and they do not occur any longer.

As I said, it is a good thing to have packages compiled against old libc-dev
packages since that actually tests whether libc6 has been true its words
when it says that its ABI is still the same.  In any case, IMHO the more
interesting question is why they shouldn't be allowed in this case?

However, my main objection to this proposal is that it solves none of your
problems as disallowing simultaneous uploads does not equate to disallowing
the building of unstable packages on stable.

So in fact you're proposing the wrong solution to your problems.  Which has
the unfortunate side effect that some maintainers will be wasting time
doing double compiles that they know will come out to be the same.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt




<strong>Acknowledgement sent</strong> to <code>Herbert Xu &lt;herbert@gondor.apana.org.au&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Herbert Xu <herbert@gondor.apana.org.au>
Subject: Bug#90511: Info received (was Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads))
Message-ID: <handler.90511.B90511.9852075422769.ackinfo@bugs.debian.org>
In-Reply-To: <200103212045.f2LKjRZ26269@gondor.apana.org.au>
References: <200103212045.f2LKjRZ26269@gondor.apana.org.au>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 20:45:42 +0000
From herbert@gondor.apana.org.au Wed Mar 21 14:45:43 2001
Return-path: <herbert@gondor.apana.org.au>
Received: from gondor.apana.org.au [203.14.152.114] (root)
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fpU8-0000h5-00; Wed, 21 Mar 2001 14:45:39 -0600
Received: (from herbert@localhost)
	by gondor.apana.org.au (8.11.1/8.11.1/Debian 8.11.0-6) id f2LKjRZ26269;
	Thu, 22 Mar 2001 07:45:27 +1100
Date: Thu, 22 Mar 2001 07:45:27 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
Message-Id: <200103212045.f2LKjRZ26269@gondor.apana.org.au>
To: Ben Collins <bcollins@debian.org>, 90511@bugs.debian.org
Subject: Re: Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
X-Newsgroups: greathan.lists.debian.bugs.dist,greathan.lists.debian.policy
In-Reply-To: <20010320230602.X28602@visi.net> <20010321131316.B28602@visi.net>
Organization: Core
User-Agent: tin/pre-1.4-980226 (UNIX) (Linux/2.4.2-586tsc (i586))
Delivered-To: 90511@bugs.debian.org

Ben Collins <bcollins@debian.org> wrote:

> As for the first. Multi distributions occur so infrequently that it
> should not be a problem to do this. Most of the time a package is
> already diverged between stable and unstable, so two uploads are still
> required in that case for security fixes. Enforcing this just means we
> have more consistency. Allowing it for convenience makes no technical
> sense.

Perhaps this has been your experience (understably since you maintain a lot
of library packages that are actively developed).  However, im my
experience, I've certainly done my fair share of "stable unstabe" uploads,
and I do not welcome the prospect of having to double those just to solve
some non-existant problem.

> As for allowing them in cases where they don't fall into any of my
> listed points of breakage, I ask that you give a solid technical reason
> why even those should be allowed, other than simple convienience. I see
> no reason for it. In fact, the only technical reason was back when we
> had frozen/unstable uploads, and they do not occur any longer.

As I said, it is a good thing to have packages compiled against old libc-dev
packages since that actually tests whether libc6 has been true its words
when it says that its ABI is still the same.  In any case, IMHO the more
interesting question is why they shouldn't be allowed in this case?

However, my main objection to this proposal is that it solves none of your
problems as disallowing simultaneous uploads does not equate to disallowing
the building of unstable packages on stable.

So in fact you're proposing the wrong solution to your problems.  Which has
the unfortunate side effect that some maintainers will be wasting time
doing double compiles that they know will come out to be the same.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] disallow multi-distribution uploads
Reply-To: Ben Collins <bcollins@debian.org>, 90511@bugs.debian.org
Resent-From: Ben Collins <bcollins@debian.org>
Orignal-Sender: Ben Collins <bmc@visi.net>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 21:03:40 GMT
Resent-Message-ID: <handler.90511.B90511.9852083448068@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.9852083448068
          (code B ref 90511); Wed, 21 Mar 2001 21:03:40 GMT
Date: Wed, 21 Mar 2001 15:58:44 -0500
From: Ben Collins <bcollins@debian.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: 90511@bugs.debian.org
Message-ID: <20010321155844.J28602@visi.net>
References: <20010320230602.X28602@visi.net> <200103210838.f2L8c8016922@gondor.apana.org.au> <20010321103756.U28602@visi.net> <20010322073118.A25574@gondor.apana.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010322073118.A25574@gondor.apana.org.au>; from herbert@gondor.apana.org.au on Thu, Mar 22, 2001 at 07:31:18AM +1100
Sender: Ben Collins <bmc@visi.net>
Delivered-To: 90511@bugs.debian.org

On Thu, Mar 22, 2001 at 07:31:18AM +1100, Herbert Xu wrote:
> On Wed, Mar 21, 2001 at 10:37:56AM -0500, Ben Collins wrote:
> > Remember that the majority of uploads to stable are done by the security
> > team and the buildd's. I don't think this is a lot of effort for the
> > maintainers, since it isn't done often enough to be cumbersome, like it
> > would have been for "frozen unstable" uploads.
> 
> Well this hasn't been the case in my experience.  Most of the security
> problems that has occured in my packages resulted in uploads by myself, not
> the security team.
> 
> > Think of a base system. If things are allowed to continue this way, it
> > means the base system will be comprised of a lot of different versions
> > of the same library. That makes a base install larger
> 
> This is a different issue.  Besides, you won't solve it by gettint people
> to do different uploads since they can compile both on stable (some
> developers only run stable machines immediately after a release).  What you
> need to here is to file bug reports against packages that compile against
> obsolete sonames.
> 
> > This isn't about keeping old libraries around. For one, people can
> > always get it from the old dist, or they will just keep it installed and
> > not remove it. This is about the libraries required by Debian packages
> > themselves. New uploads should always strive to be built agains the
> > latest packages, to reduce the dependency chain in the dist, and
> > increase integrity of the compile base.
> 
> But you won't solve the soname problem by doing this since uploading to
> unstable doesn't mean that the package was actually compiled on unstable.
> Personally bug reports have been just fine in solving this problem.
> 
> And as I said in my previous message, for libraries with the soname
> (like glibc), you do want to test it against old -dev packages to ensure
> binary compatibility.

None of these arguments says that allowing simultaneous stable/unstable
uploads has any technical merit. Disallowing it does not solve the problems
altogether, but it does raise awareness, and forbids explicitly allowing
the problems.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'




<strong>Acknowledgement sent</strong> to <code>Ben Collins &lt;bcollins@debian.org&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Ben Collins <bcollins@debian.org>
Subject: Bug#90511: Info received (was Bug#90511: proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B90511.9852083448068.ackinfo@bugs.debian.org>
In-Reply-To: <20010321155844.J28602@visi.net>
References: <20010321155844.J28602@visi.net>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 20:59:04 +0000
From bmc@visi.net Wed Mar 21 14:59:04 2001
Return-path: <bmc@visi.net>
Received: from ppp07.ts5-2.newportnews.visi.net (blimpo.internal.net) [209.8.198.71] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fph9-00025H-00; Wed, 21 Mar 2001 14:59:03 -0600
Received: from bmc by blimpo.internal.net with local (Exim 3.22 #1 (Debian))
	id 14fpgq-0002eY-00; Wed, 21 Mar 2001 15:58:44 -0500
Date: Wed, 21 Mar 2001 15:58:44 -0500
From: Ben Collins <bcollins@debian.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: 90511@bugs.debian.org
Subject: Re: Bug#90511: proposal] disallow multi-distribution uploads
Message-ID: <20010321155844.J28602@visi.net>
References: <20010320230602.X28602@visi.net> <200103210838.f2L8c8016922@gondor.apana.org.au> <20010321103756.U28602@visi.net> <20010322073118.A25574@gondor.apana.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010322073118.A25574@gondor.apana.org.au>; from herbert@gondor.apana.org.au on Thu, Mar 22, 2001 at 07:31:18AM +1100
Sender: Ben Collins <bmc@visi.net>
Delivered-To: 90511@bugs.debian.org

On Thu, Mar 22, 2001 at 07:31:18AM +1100, Herbert Xu wrote:
> On Wed, Mar 21, 2001 at 10:37:56AM -0500, Ben Collins wrote:
> > Remember that the majority of uploads to stable are done by the security
> > team and the buildd's. I don't think this is a lot of effort for the
> > maintainers, since it isn't done often enough to be cumbersome, like it
> > would have been for "frozen unstable" uploads.
> 
> Well this hasn't been the case in my experience.  Most of the security
> problems that has occured in my packages resulted in uploads by myself, not
> the security team.
> 
> > Think of a base system. If things are allowed to continue this way, it
> > means the base system will be comprised of a lot of different versions
> > of the same library. That makes a base install larger
> 
> This is a different issue.  Besides, you won't solve it by gettint people
> to do different uploads since they can compile both on stable (some
> developers only run stable machines immediately after a release).  What you
> need to here is to file bug reports against packages that compile against
> obsolete sonames.
> 
> > This isn't about keeping old libraries around. For one, people can
> > always get it from the old dist, or they will just keep it installed and
> > not remove it. This is about the libraries required by Debian packages
> > themselves. New uploads should always strive to be built agains the
> > latest packages, to reduce the dependency chain in the dist, and
> > increase integrity of the compile base.
> 
> But you won't solve the soname problem by doing this since uploading to
> unstable doesn't mean that the package was actually compiled on unstable.
> Personally bug reports have been just fine in solving this problem.
> 
> And as I said in my previous message, for libraries with the soname
> (like glibc), you do want to test it against old -dev packages to ensure
> binary compatibility.

None of these arguments says that allowing simultaneous stable/unstable
uploads has any technical merit. Disallowing it does not solve the problems
altogether, but it does raise awareness, and forbids explicitly allowing
the problems.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] disallow multi-distribution uploads
Reply-To: Herbert Xu <herbert@gondor.apana.org.au>, 90511@bugs.debian.org
Resent-From: Herbert Xu <herbert@gondor.apana.org.au>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 21:03:43 GMT
Resent-Message-ID: <handler.90511.B90511.9852084288454@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.9852084288454
          (code B ref 90511); Wed, 21 Mar 2001 21:03:43 GMT
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Mar 2001 08:00:19 +1100
To: Ben Collins <bcollins@debian.org>
Cc: 90511@bugs.debian.org
Message-ID: <20010322080019.B26477@gondor.apana.org.au>
References: <20010320230602.X28602@visi.net> <200103210838.f2L8c8016922@gondor.apana.org.au> <20010321103756.U28602@visi.net> <20010322073118.A25574@gondor.apana.org.au> <20010321155844.J28602@visi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321155844.J28602@visi.net>; from bcollins@debian.org on Wed, Mar 21, 2001 at 03:58:44PM -0500
Delivered-To: 90511@bugs.debian.org

On Wed, Mar 21, 2001 at 03:58:44PM -0500, Ben Collins wrote:
> On Thu, Mar 22, 2001 at 07:31:18AM +1100, Herbert Xu wrote:
>
> > And as I said in my previous message, for libraries with the soname
> > (like glibc), you do want to test it against old -dev packages to ensure
> > binary compatibility.
> 
> None of these arguments says that allowing simultaneous stable/unstable
> uploads has any technical merit. Disallowing it does not solve the problems
> altogether, but it does raise awareness, and forbids explicitly allowing
> the problems.

How about this point?
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt




<strong>Acknowledgement sent</strong> to <code>Herbert Xu &lt;herbert@gondor.apana.org.au&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Herbert Xu <herbert@gondor.apana.org.au>
Subject: Bug#90511: Info received (was Bug#90511: proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B90511.9852084288454.ackinfo@bugs.debian.org>
In-Reply-To: <20010322080019.B26477@gondor.apana.org.au>
References: <20010322080019.B26477@gondor.apana.org.au>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 21:00:28 +0000
From herbert@gondor.apana.org.au Wed Mar 21 15:00:28 2001
Return-path: <herbert@gondor.apana.org.au>
Received: from gondor.apana.org.au [203.14.152.114] (root)
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fpiU-0002Au-00; Wed, 21 Mar 2001 15:00:27 -0600
Received: (from herbert@localhost)
	by gondor.apana.org.au (8.11.1/8.11.1/Debian 8.11.0-6) id f2LL0KB26522;
	Thu, 22 Mar 2001 08:00:20 +1100
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Mar 2001 08:00:19 +1100
To: Ben Collins <bcollins@debian.org>
Cc: 90511@bugs.debian.org
Subject: Re: Bug#90511: proposal] disallow multi-distribution uploads
Message-ID: <20010322080019.B26477@gondor.apana.org.au>
References: <20010320230602.X28602@visi.net> <200103210838.f2L8c8016922@gondor.apana.org.au> <20010321103756.U28602@visi.net> <20010322073118.A25574@gondor.apana.org.au> <20010321155844.J28602@visi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321155844.J28602@visi.net>; from bcollins@debian.org on Wed, Mar 21, 2001 at 03:58:44PM -0500
Delivered-To: 90511@bugs.debian.org

On Wed, Mar 21, 2001 at 03:58:44PM -0500, Ben Collins wrote:
> On Thu, Mar 22, 2001 at 07:31:18AM +1100, Herbert Xu wrote:
>
> > And as I said in my previous message, for libraries with the soname
> > (like glibc), you do want to test it against old -dev packages to ensure
> > binary compatibility.
> 
> None of these arguments says that allowing simultaneous stable/unstable
> uploads has any technical merit. Disallowing it does not solve the problems
> altogether, but it does raise awareness, and forbids explicitly allowing
> the problems.

How about this point?
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] disallow multi-distribution uploads
Reply-To: Steve Greenland <stevegr@debian.org>, 90511@bugs.debian.org
Resent-From: Steve Greenland <stevegr@debian.org>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 21:19:12 GMT
Resent-Message-ID: <handler.90511.B90511.98520899814743@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.98520899814743
          (code B ref 90511); Wed, 21 Mar 2001 21:19:12 GMT
Date: Wed, 21 Mar 2001 15:09:54 -0600
From: Steve Greenland <stevegr@debian.org>
To: 90511@bugs.debian.org
Message-ID: <20010321150954.A2188@molehole.moregruel.net>
References: <20010320230602.X28602@visi.net> <20010321001902.B16878@deadbeast.net> <20010321124531.A28602@visi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321124531.A28602@visi.net>; from bcollins@debian.org on Wed, Mar 21, 2001 at 12:45:31PM -0500
Organization: Not my strong point
Mail-Copies-To: never
Delivered-To: 90511@bugs.debian.org

On 21-Mar-01, 11:45 (CST), Ben Collins <bcollins@debian.org> wrote: 
> @@ -1434,15 +1434,23 @@
>  		    </p>
>  		  </item>
>  
> -		  <tag><em>frozen</em></tag>
> +		  <tag><em>testing</em></tag>
                   ^^^^^^^

But later wrote:

> +		      is a time constraint before migration. Note, you cannot
> +		      upload directly to <em>testing</em> as you can with
> +		      <em>stable</em> and <em>unstable</em>. This distribution
> +		      is the base for the next planned release.

Did you mean "experimental" in the first part?

Steve

-- 
Steve Greenland <stevegr@debian.org>




<strong>Acknowledgement sent</strong> to <code>Steve Greenland &lt;stevegr@debian.org&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Steve Greenland <stevegr@debian.org>
Subject: Bug#90511: Info received (was Bug#90511: proposal] disallow multi-distribution uploads)
Message-ID: <handler.90511.B90511.98520899814743.ackinfo@bugs.debian.org>
In-Reply-To: <20010321150954.A2188@molehole.moregruel.net>
References: <20010321150954.A2188@molehole.moregruel.net>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 21:09:58 +0000
From steveg@molehole.dyndns.org Wed Mar 21 15:09:58 2001
Return-path: <steveg@molehole.dyndns.org>
Received: from 206.180.143.9.adsl.hal-pc.org (molehole.moregruel.net) [206.180.143.9] 
	by master.debian.org with esmtp (Exim 3.12 1 (Debian))
	id 14fprh-0003pk-00; Wed, 21 Mar 2001 15:09:58 -0600
Received: from speedy.private [192.168.1.2] (postfix)
	by molehole.moregruel.net with esmtp (Exim 3.12 #1 (Debian))
	id 14fprg-0003Jc-00; Wed, 21 Mar 2001 15:09:56 -0600
Received: by speedy.private (Postfix, from userid 1000)
	id A55764709; Wed, 21 Mar 2001 15:09:54 -0600 (CST)
Date: Wed, 21 Mar 2001 15:09:54 -0600
From: Steve Greenland <stevegr@debian.org>
To: 90511@bugs.debian.org
Subject: Re: Bug#90511: proposal] disallow multi-distribution uploads
Message-ID: <20010321150954.A2188@molehole.moregruel.net>
Reply-To: Steve Greenland <stevegr@debian.org>
References: <20010320230602.X28602@visi.net> <20010321001902.B16878@deadbeast.net> <20010321124531.A28602@visi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321124531.A28602@visi.net>; from bcollins@debian.org on Wed, Mar 21, 2001 at 12:45:31PM -0500
Organization: Not my strong point
Mail-Copies-To: never
Delivered-To: 90511@bugs.debian.org

On 21-Mar-01, 11:45 (CST), Ben Collins <bcollins@debian.org> wrote: 
> @@ -1434,15 +1434,23 @@
>  		    </p>
>  		  </item>
>  
> -		  <tag><em>frozen</em></tag>
> +		  <tag><em>testing</em></tag>
                   ^^^^^^^

But later wrote:

> +		      is a time constraint before migration. Note, you cannot
> +		      upload directly to <em>testing</em> as you can with
> +		      <em>stable</em> and <em>unstable</em>. This distribution
> +		      is the base for the next planned release.

Did you mean "experimental" in the first part?

Steve

-- 
Steve Greenland <stevegr@debian.org>




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
Reply-To: Ben Collins <bcollins@debian.org>, 90511@bugs.debian.org
Resent-From: Ben Collins <bcollins@debian.org>
Orignal-Sender: Ben Collins <bmc@visi.net>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 21:19:20 GMT
Resent-Message-ID: <handler.90511.B90511.98520940418912@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.98520940418912
          (code B ref 90511); Wed, 21 Mar 2001 21:19:20 GMT
Date: Wed, 21 Mar 2001 16:10:20 -0500
From: Ben Collins <bcollins@debian.org>
To: Herbert Xu <herbert@gondor.apana.org.au>, 90511@bugs.debian.org
Message-ID: <20010321161020.K28602@visi.net>
References: <20010320230602.X28602@visi.net> <200103212045.f2LKjRZ26269@gondor.apana.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <200103212045.f2LKjRZ26269@gondor.apana.org.au>; from herbert@gondor.apana.org.au on Thu, Mar 22, 2001 at 07:45:27AM +1100
Sender: Ben Collins <bmc@visi.net>
Delivered-To: 90511@bugs.debian.org

On Thu, Mar 22, 2001 at 07:45:27AM +1100, Herbert Xu wrote:
> Ben Collins <bcollins@debian.org> wrote:
> 
> > As for the first. Multi distributions occur so infrequently that it
> > should not be a problem to do this. Most of the time a package is
> > already diverged between stable and unstable, so two uploads are still
> > required in that case for security fixes. Enforcing this just means we
> > have more consistency. Allowing it for convenience makes no technical
> > sense.
> 
> Perhaps this has been your experience (understably since you maintain a lot
> of library packages that are actively developed).  However, im my
> experience, I've certainly done my fair share of "stable unstabe" uploads,
> and I do not welcome the prospect of having to double those just to solve
> some non-existant problem.

Yes it does help. By allowing stable/unstable uploads, we implicitly
allow maintainers to do something potentially harmful and with almost
zero technical gain. By disallowing it, we raise awareness that it is
most commonly not a good idea.

> > As for allowing them in cases where they don't fall into any of my
> > listed points of breakage, I ask that you give a solid technical reason
> > why even those should be allowed, other than simple convienience. I see
> > no reason for it. In fact, the only technical reason was back when we
> > had frozen/unstable uploads, and they do not occur any longer.
> 
> As I said, it is a good thing to have packages compiled against old libc-dev
> packages since that actually tests whether libc6 has been true its words
> when it says that its ABI is still the same.  In any case, IMHO the more
> interesting question is why they shouldn't be allowed in this case?

Testing libc6 backward compatibility is not the purpose of
stable/unstable uploads. That is something that needs to be tested
elsewhere. Allowing stable/unstable uploads does not guarantee any of
this, and is a bad way to test it. For example, many packages should be
using new interfaces in libc6 for LFS, and not using the db libraries
that were obsoleted. Compiling against potato increases the lack of LFS
support in our unstable distribution, and increases the use of obsoleted
parts of libc6. Neither of these things are technically meritable.

So if you want to test libc6, then get a potato and a sid machine (or
setup a chroot), and compile your package for potato, and run it in the
sid system. Don't go uploading a potato compiled package to sid just to
test libc6's binary compatibility.

> However, my main objection to this proposal is that it solves none of your
> problems as disallowing simultaneous uploads does not equate to disallowing
> the building of unstable packages on stable.
> 
> So in fact you're proposing the wrong solution to your problems.  Which has
> the unfortunate side effect that some maintainers will be wasting time
> doing double compiles that they know will come out to be the same.

No, I'm proposing a large portion of the fix. The other portion may be
needed, if the problems persist. No amount of policy can stop this
completely, even if we forbid (and enforce via dinstall) not using
oldlibs as deps, since that doesn't enforce policy things like doc
directories and X application defaults, and buildability on unstable.

You still have not given any technical merit to allowing stable/unstable
uploads other than convenience, which is not on my list of technical
terms.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'




<strong>Acknowledgement sent</strong> to <code>Ben Collins &lt;bcollins@debian.org&gt;</code>:<br>
Extra info received and forwarded to list.  Copy sent to <code>Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>.


-t

From: owner@bugs.debian.org (Debian Bug Tracking System)
To: Ben Collins <bcollins@debian.org>
Subject: Bug#90511: Info received (was Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads))
Message-ID: <handler.90511.B90511.98520940418912.ackinfo@bugs.debian.org>
In-Reply-To: <20010321161020.K28602@visi.net>
References: <20010321161020.K28602@visi.net>
X-Debian-PR-Message: ack-info-maintonly 90511

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the developer(s) and
to the developers mailing list to accompany the original report.

Your message has been sent to the package maintainer(s):
 Debian Policy List <debian-policy@lists.debian.org>

If you wish to continue to submit further information on your problem,
please send it to 90511@bugs.debian.org, as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Darren Benham
(administrator, Debian Bugs database)



Received: (at 90511) by bugs.debian.org; 21 Mar 2001 21:16:44 +0000
From bmc@visi.net Wed Mar 21 15:16:44 2001
Return-path: <bmc@visi.net>
Received: from murphy.debian.org [216.234.231.6] 
	by master.debian.org with smtp (Exim 3.12 1 (Debian))
	id 14fpyF-0004uo-00; Wed, 21 Mar 2001 15:16:43 -0600
Received: (qmail 30238 invoked from network); 21 Mar 2001 21:15:34 -0000
Received: from ppp07.ts5-2.newportnews.visi.net (HELO blimpo.internal.net) (209.8.198.71)
  by murphy.debian.org with SMTP; 21 Mar 2001 21:15:34 -0000
Received: from bmc by blimpo.internal.net with local (Exim 3.22 #1 (Debian))
	id 14fps4-0002ff-00; Wed, 21 Mar 2001 16:10:20 -0500
Date: Wed, 21 Mar 2001 16:10:20 -0500
From: Ben Collins <bcollins@debian.org>
To: Herbert Xu <herbert@gondor.apana.org.au>, 90511@bugs.debian.org
Subject: Re: Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
Message-ID: <20010321161020.K28602@visi.net>
References: <20010320230602.X28602@visi.net> <200103212045.f2LKjRZ26269@gondor.apana.org.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <200103212045.f2LKjRZ26269@gondor.apana.org.au>; from herbert@gondor.apana.org.au on Thu, Mar 22, 2001 at 07:45:27AM +1100
Sender: Ben Collins <bmc@visi.net>
Delivered-To: 90511@bugs.debian.org

On Thu, Mar 22, 2001 at 07:45:27AM +1100, Herbert Xu wrote:
> Ben Collins <bcollins@debian.org> wrote:
> 
> > As for the first. Multi distributions occur so infrequently that it
> > should not be a problem to do this. Most of the time a package is
> > already diverged between stable and unstable, so two uploads are still
> > required in that case for security fixes. Enforcing this just means we
> > have more consistency. Allowing it for convenience makes no technical
> > sense.
> 
> Perhaps this has been your experience (understably since you maintain a lot
> of library packages that are actively developed).  However, im my
> experience, I've certainly done my fair share of "stable unstabe" uploads,
> and I do not welcome the prospect of having to double those just to solve
> some non-existant problem.

Yes it does help. By allowing stable/unstable uploads, we implicitly
allow maintainers to do something potentially harmful and with almost
zero technical gain. By disallowing it, we raise awareness that it is
most commonly not a good idea.

> > As for allowing them in cases where they don't fall into any of my
> > listed points of breakage, I ask that you give a solid technical reason
> > why even those should be allowed, other than simple convienience. I see
> > no reason for it. In fact, the only technical reason was back when we
> > had frozen/unstable uploads, and they do not occur any longer.
> 
> As I said, it is a good thing to have packages compiled against old libc-dev
> packages since that actually tests whether libc6 has been true its words
> when it says that its ABI is still the same.  In any case, IMHO the more
> interesting question is why they shouldn't be allowed in this case?

Testing libc6 backward compatibility is not the purpose of
stable/unstable uploads. That is something that needs to be tested
elsewhere. Allowing stable/unstable uploads does not guarantee any of
this, and is a bad way to test it. For example, many packages should be
using new interfaces in libc6 for LFS, and not using the db libraries
that were obsoleted. Compiling against potato increases the lack of LFS
support in our unstable distribution, and increases the use of obsoleted
parts of libc6. Neither of these things are technically meritable.

So if you want to test libc6, then get a potato and a sid machine (or
setup a chroot), and compile your package for potato, and run it in the
sid system. Don't go uploading a potato compiled package to sid just to
test libc6's binary compatibility.

> However, my main objection to this proposal is that it solves none of your
> problems as disallowing simultaneous uploads does not equate to disallowing
> the building of unstable packages on stable.
> 
> So in fact you're proposing the wrong solution to your problems.  Which has
> the unfortunate side effect that some maintainers will be wasting time
> doing double compiles that they know will come out to be the same.

No, I'm proposing a large portion of the fix. The other portion may be
needed, if the problems persist. No amount of policy can stop this
completely, even if we forbid (and enforce via dinstall) not using
oldlibs as deps, since that doesn't enforce policy things like doc
directories and X application defaults, and buildability on unstable.

You still have not given any technical merit to allowing stable/unstable
uploads other than convenience, which is not on my list of technical
terms.

-- 
 -----------=======-=-======-=========-----------=====------------=-=------
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '
 `---=========------=======-------------=-=-----=-===-======-------=--=---'




<strong>Information forwarded</strong> to <code>debian-bugs-dist@lists.debian.org, Debian Policy List &lt;debian-policy@lists.debian.org&gt;</code>:<br>
<code>Bug#90511</code>; Package <code>debian-policy</code>.


debian-bugs-dist@lists.debian.orgDebian Policy List <debian-policy@lists.debian.org>

Subject: Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)
Reply-To: Herbert Xu <herbert@gondor.apana.org.au>, 90511@bugs.debian.org
Resent-From: Herbert Xu <herbert@gondor.apana.org.au>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: Debian Policy List <debian-policy@lists.debian.org>
Resent-Date: Wed, 21 Mar 2001 21:33:42 GMT
Resent-Message-ID: <handler.90511.B90511.98520976921192@bugs.debian.org>
Resent-Sender: owner@bugs.debian.org
X-Debian-PR-Message: report 90511
X-Debian-PR-Package: debian-policy
X-Debian-PR-Keywords: 
X-Loop: owner@bugs.debian.org
Received: via spool by 90511-bugs@bugs.debian.org id=B90511.98520976921192
          (code B ref 90511); Wed, 21 Mar 2001 21:33:42 GMT
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Mar 2001 08:22:40 +1100
To: Ben Collins <bcollins@debian.org>
Cc: 90511@bugs.debian.org
Message-ID: <20010322082240.A26914@gondor.apana.org.au>
References: <20010320230602.X28602@visi.net> <200103212045.f2LKjRZ26269@gondor.apana.org.au> <20010321161020.K28602@visi.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <20010321161020.K28602@visi.net>; from bcollins@debian.org on Wed, Mar 21, 2001 at 04:10:20PM -0500
Delivered-To: 90511@bugs.debian.org

On Wed, Mar 21, 2001 at 04:10:20PM -0500, Ben Collins wrote:
> 
> Yes it does help. By allowing stable/unstable uploads, we implicitly
> allow maintainers to do something potentially harmful and with almost
> zero technical gain. By disallowing it, we raise awareness that it is
> most commonly not a good idea.

IMHO you can't solve social problems with technial solutions.

> Testing libc6 backward compatibility is not the purpose of
> stable/unstable uploads. That is something that needs to be tested

But it is a side effect for packages depending on libc6.

> elsewhere. Allowing stable/unstable uploads does not guarantee any of
> this, and is a bad way to test it. For example, many packages should be
> using new interfaces in libc6 for LFS, and not using the db libraries
> that were obsoleted. Compiling against potato increases the lack of LFS
> support in our unstable distribution, and increases the use of obsoleted
> parts of libc6. Neither of these things are technically meritable.

As I have said many times already, this is a *different* problem.

If a package can benefit from LFS