Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[AndreasSchulz]

- Original Message -
From: "Ben Collins" <[EMAIL PROTECTED]>
To: "Herbert Xu" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 22, 2001 3:23 AM
Subject: Bug#90511: proposal] addressing objections (re: disallow
multi-distribution uploads)


> On Thu, Mar 22, 2001 at 12:42:57PM +1100, Herbert Xu wrote:
> > On Wed, Mar 21, 2001 at 04:51:06PM -0500, Ben Collins wrote:
> > > On Thu, Mar 22, 2001 at 08:42:16AM +1100, Herbert Xu wrote:
> > >
> > > > Are you saying that packages compiled against old libc6-dev packages
are
> > > > not guarranteed to work with a new libc6? Well, better tell that to
all
> > > > the application vendors out there.
> > >
> > > No, but other libraries may show this problem. Not just that, but
> >
> > Any libraries which change the ABI without changing the soname is buggy,
> > period.
>
> Agreed. However, uploading to "stable unstable" is not the correct nor
> intended manner to test them.
>
> > > compiling against libc6-dev 2.1.3 does not mean it will compile
against
> > > libc6-dev 2.2.2
> >
> > That's a different problem.
>
> Correct, but one which we help to avoid with this proposal, and hope to
> alleviate by raising awareness of the seperation.
>
> > > No, you misinterpret this. I am saying that if you build against
> > > "stable" (see above, that is what I said), then the buildd's will
> > > compile against unstable for an unstable upload. So you argument about
> > > allowing testing of backward compatibility applies here. You are
> > > creating feature skew.
> >
> > Well for "stable unstable" uploads, the buildd should build it on
stable,
> > and upload it to "stable unstable".  IIRC this is what you said in your
> > first message.
>
> It does. However, your argument was based on the "helpfulness" of
> building on stable and uploading to unstable. None of which is pertinent
> to this proposal.
>
> > > > Disallowing "stable unstable" uploads has a very small effect on
this.
> > >
> > > That's arguable, and not technically founded. However, allowing
> > > stable/unstable uploads implicitly allows this to happen. So if we
> > > enforce this in the long run, as you suggest, we will have to stop
> > > stable/unstable uploads anyway.
> >
> > Not for me.  Most of my "stable unstable" uploads are for the kernels
> > which do not interact with libraries in any way.
>
> An excellent point. This is about the only valid thing I can forsee
> against this. Quite often builds are done for stable/unstable of kernels
> (I've done some myself for sparc kernels). I'll have to consider this
> one point. However, even with this, you do use a compiler and binutils
> that are quite different between the distributions. Take the upcoming
> gcc3, which will soon replace gcc-2.95 as the system compiler. We will
> have a period where the stable has gcc-2.95 and unstable has gcc-3.0.
> Should not the kernels be buildable by the compiler of the distribution
> for which they are uploaded to?
>
> > > Of course they are. It means the packages have to be compiled on
stable
> > > and uploaded to unstable. It means there is no way around that, and
> > > problems do occur because of it. By disallowing them, we are a step
> >
> > Well my point is that disallowing "stable unstable" doesn't solve those
> > problems for most packages, as "stable unstable" uploads are rare to
start
> > with.  And for packages which don't have these problems, this incurs
> > significant overhead on the part of the maintainer.
>
> Actually they are less rare than you think. Most of the builds done by
> the security team incur this, since that usually means the maintainer
> isn't active (and hasn't been since stable released). I don't think the
> rareness of this event outweighs it's purpose since the problems are of
> a severity that justifies it, IMHO of course.
>
> --
>  ---===-=-==-=---==-=-
-
> /  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux
\
> `  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]
'
>
`---=--===-=-=-=-===-==---=--=---'
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
>
>

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[James Troup]

"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes:

> >> Ben Collins <[EMAIL PROTECTED]> writes:
> 
>  > Yes, proposed updates do go into the pool.
> 
>  Interesting.  Which Packages file points to them?  Certainly not
>  stable's (at least not for a while), certainly not unstable's (not
>  permanently, at least), and would think neither testing's.  What's
>  left?

Err, proposed-updates' Packages file, perhaps?

-- 
James

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Ben Collins]

On Thu, Mar 22, 2001 at 08:14:13PM +0100, Marcelo E. Magallon wrote:
> >> Ben Collins <[EMAIL PROTECTED]> writes:
> 
>  > Yes, proposed updates do go into the pool.
> 
>  Interesting.  Which Packages file points to them?  Certainly not
>  stable's (at least not for a while), certainly not unstable's (not
>  permanently, at least), and would think neither testing's.  What's
>  left?

The Packages file in the proposed-updates directory.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Marcelo E. Magallon]

>> Ben Collins <[EMAIL PROTECTED]> writes:

 > Yes, proposed updates do go into the pool.

 Interesting.  Which Packages file points to them?  Certainly not
 stable's (at least not for a while), certainly not unstable's (not
 permanently, at least), and would think neither testing's.  What's
 left?

-- 
Marcelo

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Ben Collins]

On Thu, Mar 22, 2001 at 06:16:43PM +0100, Marcus Brinkmann wrote:
> On Thu, Mar 22, 2001 at 10:44:17AM -0600, Manoj Srivastava wrote:
> > 
> > The stable package need not go into the package pool. Am I
> >  mistaken in assuming that proposed updates packages are not in the
> >  package pool? If I am mistaken, please scratch this part of my
> >  message. 
> 
> I don't know. If it is, then you can scratch my messages instead.

Yes, proposed updates do go into the pool.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Marcus Brinkmann]

On Thu, Mar 22, 2001 at 10:44:17AM -0600, Manoj Srivastava wrote:
>  >> There is not technical reason
>  >> for not building uploads to stable unstable twice in buildd either. 
> 
>  Marcus> I think this is not true. What is meant by this? It means
>  Marcus> building the same package twice, with the same version
>  Marcus> number, but the source  (debian/changelog) modified to read
>  Marcus> "stable" and "unstable" each once. 
> 
>   Umm. No. If I have two buildd's, one for unstable, and one for
>  stable. When a package comes in for unstable, it goes to the unstable
>  buildd, and vice versa. When a package comes in for both, it is sent
>  to both buildd's, and the packlage built by the unstable buildd goes
>  into incoming normally, and the other one is hand installed by an
>  admin into proposed updates or something. 

Proposed updates. So. That's a factor I did not include in my calculation.
(In Germany one would say "you catched me on the cold foot" ;)

>  Marcus> Having two different packages with the same version number is
>  Marcus> evil, too. The package pool won't be able to cope for good
>  Marcus> reasons. 
> 
>   The stable package need not go into the package pool. Am I
>  mistaken in assuming that proposed updates packages are not in the
>  package pool? If I am mistaken, please scratch this part of my
>  message. 

I don't know. If it is, then you can scratch my messages instead.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Manoj Srivastava]

>>"Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes:

 Marcus> Are you sure you wanted to say "multiple versions of a
 Marcus> package in the same distribution"? In my opinion, "one
 Marcus> version of a package in multiple distributions" fits better
 Marcus> in the context. 

 Marcus> If the latter is meant, I concur.

Hmm. I guess I did mean the latter. With age, the wiring in my
 brain is certainly getting stranger. 

 >> There is not technical reason
 >> for not building uploads to stable unstable twice in buildd either. 

 Marcus> I think this is not true. What is meant by this? It means
 Marcus> building the same package twice, with the same version
 Marcus> number, but the source  (debian/changelog) modified to read
 Marcus> "stable" and "unstable" each once. 

Umm. No. If I have two buildd's, one for unstable, and one for
 stable. When a package comes in for unstable, it goes to the unstable
 buildd, and vice versa. When a package comes in for both, it is sent
 to both buildd's, and the packlage built by the unstable buildd goes
 into incoming normally, and the other one is hand installed by an
 admin into proposed updates or something. 


 Marcus> Modifying the source is evil. Autobuilders should not do
 Marcus> this.

I was not proposing modification of the source, no. 

 Marcus> Having two different packages with the same version number is
 Marcus> evil, too. The package pool won't be able to cope for good
 Marcus> reasons. 

The stable package need not go into the package pool. Am I
 mistaken in assuming that proposed updates packages are not in the
 package pool? If I am mistaken, please scratch this part of my
 message. 


 Marcus> I think one of the requirements for uploading to "stable
 Marcus> unstable" should be that the package can be build on either
 Marcus> and will run fine on both, so autobuilders are relieved from
 Marcus> making a decision. I could agree with setting in stone a
 Marcus> variation like: "the package must be build on stable and will
 Marcus> run fine on both" (or build on unstable and run on both). 

The latter is less likely than the former, since libraries are
 rarely forward compatible across releases. 

 Marcus> But unless I am very mistaken, we must have one such rule for
 Marcus> autobuilders and maintainers to follow.

I would not disagree.

manoj
-- 
 Do you know Montana?
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Marcus Brinkmann]

On Thu, Mar 22, 2001 at 08:23:20AM -0600, Manoj Srivastava wrote:
>   No, you have outlined problems in dinstall and the buildd
>  process. There is inherently no reason not to have multiple versions
>  of a package in the same distribution using package pools, apart from
>  the current implementation of dinstall.

Are you sure you wanted to say "multiple versions of a package in the same
distribution"? In my opinion, "one version of a package in multiple
distributions" fits better in the context.

If the latter is meant, I concur.

>  There is not technical reason
>  for not building uploads to stable unstable twice in buildd either. 

I think this is not true. What is meant by this? It means building the same
package twice, with the same version number, but the source
(debian/changelog) modified to read "stable" and "unstable" each once.

Modifying the source is evil. Autobuilders should not do this.
Having two different packages with the same version number is evil, too.
The package pool won't be able to cope for good reasons.

I think one of the requirements for uploading to "stable unstable" should be
that the package can be build on either and will run fine on both, so
autobuilders are relieved from making a decision. I could agree with setting
in stone a variation like: "the package must be build on stable and will run
fine on both" (or build on unstable and run on both).

But unless I am very mistaken, we must have one such rule for autobuilders and
maintainers to follow.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Manoj Srivastava]

>>"Ben" == Ben Collins <[EMAIL PROTECTED]> writes:

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

You now have wnother one: There is little technical merit in
 disallowing the uploads, since it is not forbidden to build packages
 for unstable on stable systems. Given that fact, if a package is
 built in stable, and uploaded to unstable as well (perfectly legal
 under the current and proposed policy), there is no benefit
 whatsoever to imposing this arbitary rule. 

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

Infrequency of uploads is not a technical argument. If
 something is right, how infrequently it occurs is irrelevant. 


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

No. You are asking for a policy change. The burden is on you
 to provide a solid reason for changing, other than flaws in dinstall
 and buildd.  

manoj
-- 
 AmigaDOS Beer: The company has gone out of business, but their recipe
 has been picked up by some weird German company, so now this beer
 will be an import.  This beer never really sold very well because the
 original manufacturer didn't understand marketing. Like Unix Beer,
 AmigaDOS Beer fans are an extremely loyal and loud group. It
 originally came in a 16-oz. can, but now comes in 32-oz.  cans too.
 When this can was originally introduced, it appeared flashy and
 colorful, but the design hasn't changed much over the years, so it
 appears dated now.  Critics of this beer claim that it is only meant
 for watching TV anyway.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Manoj Srivastava]

>>"Ben" == Ben Collins <[EMAIL PROTECTED]> writes:

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

You've gotta be kidding.

Something potentially harmful? Firstly, that is debateable,
 making people do two uploads is also potentially harmful, and  you
 are not mandating the unstable build be done on a unstable box in the
 first place. 

Arguably, using helper packages without knowing what the hell
 is going on behind the scenes is a potentially dangerous
 practice. Should policy now ban helper packages?

Hell, UNIX allows people to do potentially dangerous things. 


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

Disallowing convenience to work around possible design flaws
 in an unrelated process is not my idea of doing the right thing
 either. 

manoj
-- 
 Chicken Little only has to be right once.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Manoj Srivastava]

>>"Ben" == Ben Collins <[EMAIL PROTECTED]> writes:

 Ben> What is a legitimate reason for uploading to stable/unstable other than
 Ben> convience? I see none.

Is there a reason for policy to disallow convenience
 (incidentally, what reason is there to use helper packages other than
 convenience?

 Ben> However, there are inherent problems with allowing
 Ben> stable/unstable uploads, which I have outlined.

No, you have outlined problems in dinstall and the buildd
 process. There is inherently no reason not to have multiple versions
 of a package in the same distribution using package pools, apart from
 the current implementation of dinstall. There is not technical reason
 for not building uploads to stable unstable twice in buildd either. 

 Ben> Because of that, and because there are no technical reasons
 Ben> otherwise, I feel that they should be disallowed, to prevent the
 Ben> problems.

Fix the root of the problem. Making people do two uploads
 because of flaws in the process should not be enshrined in policy. 

manoj
-- 
 "Consistency requires you to be as ignorant today as you were a year
 ago." Bernard Berenson
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Julian Gilbey]

On Wed, Mar 21, 2001 at 01:13:17PM -0500, Ben Collins wrote:
> 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.

We have yet to see what a freeze in the new setup actually looks
like.  It has been discussed, but no conclusion reached, AFAIK.  I
don't know what aj is planning to do, ultimately.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Ben Collins]

> 
> Your proposal is exactly like throwing the bash with the baby (sorry, don't
> remember the exact wording).
> 

It's "throwing out the baby with the bath water" :)

And you are probably right. Some of Manoj's points are setting in. The
only thing is that this requires a lot of checking on dinstall's end,
and I'm concerned about how to implement such things.

I'm going to put this proposal on hold till I think over some of the
details.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Santiago Vila]

On Wed, 21 Mar 2001, Ben Collins wrote:

> On Thu, Mar 22, 2001 at 12:11:43AM +0100, Santiago Vila wrote:
> >
> > If there is need of a technical reason here, we need a technical
> > reason to forbid legitimate uploads, which is (one of the things) your
> > proposal would do.
>
> What is a legitimate reason for uploading to stable/unstable other than
> convience? I see none. However, there are inherent problems with
> allowing stable/unstable uploads, which I have outlined.

No, they are not *inherent*. There is just a small statistical
correlation between uploads to "stable unstable" and the problems you
describe, but the mere fact of uploading to "stable unstable" is not
the *real* cause of those problems.

This is like saying "car produce accidents, let's forbid cars" or "Is there
a reason to use cars other than convenience?".

Are you aware the forcing people to make some uploads twice opens the
door for another different source of possible mistakes? It seems that
the only mistakes you take in account are those that you want to take
in account.

Your proposal is exactly like throwing the bash with the baby (sorry, don't
remember the exact wording).

> Because of that, and because there are no technical reasons otherwise,
> I feel that they should be disallowed, to prevent the problems.

I'm afraid about what will you disallow next.

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Herbert Xu]

On Wed, Mar 21, 2001 at 09:23:08PM -0500, Ben Collins wrote:
> On Thu, Mar 22, 2001 at 12:42:57PM +1100, Herbert Xu wrote:
>
> > Any libraries which change the ABI without changing the soname is buggy,
> > period.
> 
> Agreed. However, uploading to "stable unstable" is not the correct nor
> intended manner to test them.

Agreed.  It is just a side effect.  Which I argue is also the case with
your proposal.  What you are trying to achieve is merely a side effect,
and one which can be done by other means which are less intrusive.

Please give me your opinions about my proposal to solve your complaint
about obsolete libraries in unstable.  In fact, the LFS problem can be
solved through similar mechanism: we can enforce a minimum versioned
dependency in the package (if it depended on libc6 at all that is).

> > > compiling against libc6-dev 2.1.3 does not mean it will compile against
> > > libc6-dev 2.2.2
> > 
> > That's a different problem.
> 
> Correct, but one which we help to avoid with this proposal, and hope to
> alleviate by raising awareness of the seperation.

My main problem with this whole proposal is that it's trying to decide
for the maintainer as to whether a separate unstable upload is necessary.
My contention is that the maintainer is be the best person to make
that judgement.

If you point is that there are maintainers out there who may not be aware
of the potential problems with "stable unstable", then perhaps we should
start by informing them of the issues involved?

> It does. However, your argument was based on the "helpfulness" of
> building on stable and uploading to unstable. None of which is pertinent
> to this proposal.

Point taken.

> An excellent point. This is about the only valid thing I can forsee
> against this. Quite often builds are done for stable/unstable of kernels
> (I've done some myself for sparc kernels). I'll have to consider this
> one point. However, even with this, you do use a compiler and binutils
> that are quite different between the distributions. Take the upcoming
> gcc3, which will soon replace gcc-2.95 as the system compiler. We will
> have a period where the stable has gcc-2.95 and unstable has gcc-3.0.
> Should not the kernels be buildable by the compiler of the distribution
> for which they are uploaded to?

We take which ever one that produces correct code.  If they both do, then
it doesn't matter.

However, I have been doing other "stable unstable" uploads as well, mostly
when there are security holes in my packages.  And for the vast majority of
them, I can say that they had none of the pit falls that you have enumerated.
So should this restriction be enforced, I would have to double my efforts
in those cases.  Which probably means that unstable will suffer by getting
security fixes later than it would otherwise.

Let me reiterate my main objection to this: the maintainer is the best
person to weigh all the factors involved and to decide whether given that
stable/unstable shares a version to start with, whether to split or
continue to use the same package for both.  I don't see why we shouldn't
trust them with this task.

> Actually they are less rare than you think. Most of the builds done by
> the security team incur this, since that usually means the maintainer
> isn't active (and hasn't been since stable released). I don't think the
> rareness of this event outweighs it's purpose since the problems are of
> a severity that justifies it, IMHO of course.

Well if that's the case, then a similar result can be achived by just
forbidding the security team from doing "stable unstable" uploads.  I
wouldn't have a problem with that since I don't plan on joining them :)
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Ben Collins]

On Thu, Mar 22, 2001 at 03:09:30AM +0100, Marcus Brinkmann wrote:
> On Thu, Mar 22, 2001 at 12:42:57PM +1100, Herbert Xu wrote:
> > Well my point is that disallowing "stable unstable" doesn't solve those
> > problems for most packages, as "stable unstable" uploads are rare to start
> > with.  And for packages which don't have these problems, this incurs
> > significant overhead on the part of the maintainer.
> 
> There are indeed some packages were it doesn't matter where you build it,
> and where the interfaces don't change between Debian revisions.
> 
> I think the cases are few, but there is no need to burden the maintainers in
> those cases, even when Bens proposal gets accepted.
> 
> I suggest for these cases that the upload is done for unstable (only),
> and a bug report is filed against ftp.debian.org or some other suitable
> virtual package (for example "stable-releases"), requesting inclusion
> into stable. This is not a lot of work. The release manager needs to
> look at this place of course, instead in the upload queue. It's just a
> matter of how to communicate it to the release manager. Do you think
> this is a workable compromise?

That should be possible for the ftp-admins to do given the pgsql
database interface. However, I would like them to comment on how much of
a burden they think it is.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Ben Collins]

On Thu, Mar 22, 2001 at 12:42:57PM +1100, Herbert Xu wrote:
> On Wed, Mar 21, 2001 at 04:51:06PM -0500, Ben Collins wrote:
> > On Thu, Mar 22, 2001 at 08:42:16AM +1100, Herbert Xu wrote:
> >
> > > Are you saying that packages compiled against old libc6-dev packages are
> > > not guarranteed to work with a new libc6? Well, better tell that to all
> > > the application vendors out there.
> > 
> > No, but other libraries may show this problem. Not just that, but
> 
> Any libraries which change the ABI without changing the soname is buggy,
> period.

Agreed. However, uploading to "stable unstable" is not the correct nor
intended manner to test them.

> > compiling against libc6-dev 2.1.3 does not mean it will compile against
> > libc6-dev 2.2.2
> 
> That's a different problem.

Correct, but one which we help to avoid with this proposal, and hope to
alleviate by raising awareness of the seperation.

> > No, you misinterpret this. I am saying that if you build against
> > "stable" (see above, that is what I said), then the buildd's will
> > compile against unstable for an unstable upload. So you argument about
> > allowing testing of backward compatibility applies here. You are
> > creating feature skew.
> 
> Well for "stable unstable" uploads, the buildd should build it on stable,
> and upload it to "stable unstable".  IIRC this is what you said in your
> first message.

It does. However, your argument was based on the "helpfulness" of
building on stable and uploading to unstable. None of which is pertinent
to this proposal.

> > > Disallowing "stable unstable" uploads has a very small effect on this.
> > 
> > That's arguable, and not technically founded. However, allowing
> > stable/unstable uploads implicitly allows this to happen. So if we
> > enforce this in the long run, as you suggest, we will have to stop
> > stable/unstable uploads anyway.
> 
> Not for me.  Most of my "stable unstable" uploads are for the kernels
> which do not interact with libraries in any way.

An excellent point. This is about the only valid thing I can forsee
against this. Quite often builds are done for stable/unstable of kernels
(I've done some myself for sparc kernels). I'll have to consider this
one point. However, even with this, you do use a compiler and binutils
that are quite different between the distributions. Take the upcoming
gcc3, which will soon replace gcc-2.95 as the system compiler. We will
have a period where the stable has gcc-2.95 and unstable has gcc-3.0.
Should not the kernels be buildable by the compiler of the distribution
for which they are uploaded to?

> > Of course they are. It means the packages have to be compiled on stable
> > and uploaded to unstable. It means there is no way around that, and
> > problems do occur because of it. By disallowing them, we are a step
> 
> Well my point is that disallowing "stable unstable" doesn't solve those
> problems for most packages, as "stable unstable" uploads are rare to start
> with.  And for packages which don't have these problems, this incurs
> significant overhead on the part of the maintainer.

Actually they are less rare than you think. Most of the builds done by
the security team incur this, since that usually means the maintainer
isn't active (and hasn't been since stable released). I don't think the
rareness of this event outweighs it's purpose since the problems are of
a severity that justifies it, IMHO of course.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Marcus Brinkmann]

On Thu, Mar 22, 2001 at 12:42:57PM +1100, Herbert Xu wrote:
> Well my point is that disallowing "stable unstable" doesn't solve those
> problems for most packages, as "stable unstable" uploads are rare to start
> with.  And for packages which don't have these problems, this incurs
> significant overhead on the part of the maintainer.

There are indeed some packages were it doesn't matter where you build it,
and where the interfaces don't change between Debian revisions.

I think the cases are few, but there is no need to burden the maintainers in
those cases, even when Bens proposal gets accepted.

I suggest for these cases that the upload is done for unstable (only),
and a bug report is filed against ftp.debian.org or some other suitable
virtual package (for example "stable-releases"), requesting inclusion
into stable. This is not a lot of work. The release manager needs to
look at this place of course, instead in the upload queue. It's just a
matter of how to communicate it to the release manager. Do you think
this is a workable compromise?

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Herbert Xu]

On Wed, Mar 21, 2001 at 04:51:06PM -0500, Ben Collins wrote:
> On Thu, Mar 22, 2001 at 08:42:16AM +1100, Herbert Xu wrote:
>
> > Are you saying that packages compiled against old libc6-dev packages are
> > not guarranteed to work with a new libc6? Well, better tell that to all
> > the application vendors out there.
> 
> No, but other libraries may show this problem. Not just that, but

Any libraries which change the ABI without changing the soname is buggy,
period.

> compiling against libc6-dev 2.1.3 does not mean it will compile against
> libc6-dev 2.2.2

That's a different problem.

> No, you misinterpret this. I am saying that if you build against
> "stable" (see above, that is what I said), then the buildd's will
> compile against unstable for an unstable upload. So you argument about
> allowing testing of backward compatibility applies here. You are
> creating feature skew.

Well for "stable unstable" uploads, the buildd should build it on stable,
and upload it to "stable unstable".  IIRC this is what you said in your
first message.

> > Disallowing "stable unstable" uploads has a very small effect on this.
> 
> That's arguable, and not technically founded. However, allowing
> stable/unstable uploads implicitly allows this to happen. So if we
> enforce this in the long run, as you suggest, we will have to stop
> stable/unstable uploads anyway.

Not for me.  Most of my "stable unstable" uploads are for the kernels
which do not interact with libraries in any way.

> Of course they are. It means the packages have to be compiled on stable
> and uploaded to unstable. It means there is no way around that, and
> problems do occur because of it. By disallowing them, we are a step

Well my point is that disallowing "stable unstable" doesn't solve those
problems for most packages, as "stable unstable" uploads are rare to start
with.  And for packages which don't have these problems, this incurs
significant overhead on the part of the maintainer.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Ben Collins]

On Thu, Mar 22, 2001 at 12:11:43AM +0100, Santiago Vila wrote:
> 
> If there is need of a technical reason here, we need a technical
> reason to forbid legitimate uploads, which is (one of the things) your
> proposal would do.
> 

What is a legitimate reason for uploading to stable/unstable other than
convience? I see none. However, there are inherent problems with
allowing stable/unstable uploads, which I have outlined. Because of
that, and because there are no technical reasons otherwise, I feel that
they should be disallowed, to prevent the problems.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Santiago Vila]

Ben Collins wrote:
> So, if those objecters will adress my counter-objection to them, I will
> concede the objection.

If you think my objection is gratuitous, I think your proposal is
gratuitous too. I'm sorry but objections are not "conceded" by people
doing policy proposals. They just happen as part of the policy
process. If you disagree you have to change the policy process itself.

"First they forbid source-only uploads, but since I did not do
source-only uploads I didn't care. Then they forbid uploads to
`stable unstable', but since I didn't do such uploads I didn't care either
[...]". Does this ring a bell?

Debian is about freedom, and policy should not forbid things "just in
case". We should only forbid things because they are bad, and uploads
to "stable unstable" are not inherently bad *per se*.

My reason for objecting is that it also forbids *legitimate* uploads.
We should not forbid things that should not be forbidden. It's that simple.

If there is need of a technical reason here, we need a technical
reason to forbid legitimate uploads, which is (one of the things) your
proposal would do.

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Ben Collins]

On Thu, Mar 22, 2001 at 08:42:16AM +1100, Herbert Xu wrote:
> On Wed, Mar 21, 2001 at 04:35:58PM -0500, Ben Collins wrote:
> > 
> > > > 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.
> > 
> > And side affects are often bad, as they have unforseen problems.
> 
> Are you saying that packages compiled against old libc6-dev packages are
> not guarranteed to work with a new libc6? Well, better tell that to all
> the application vendors out there.

No, but other libraries may show this problem. Not just that, but
compiling against libc6-dev 2.1.3 does not mean it will compile against
libc6-dev 2.2.2

> > against stable. Yes bug reports can do this. However, when you upload a
> > package built against stable, the buildd's use unstable, so now you have
> > feature skew across architectures. That is a bad thing.
> 
> Here's the crux of your current problem.  The buildd is broken.  In your
> original message, you actually said that the buildd should build on stable
> for such uploads, which would be the correct thing.

No, you misinterpret this. I am saying that if you build against
"stable" (see above, that is what I said), then the buildd's will
compile against unstable for an unstable upload. So you argument about
allowing testing of backward compatibility applies here. You are
creating feature skew.

> > Also, we want our latest features to be tested. Compiling against stable
> > does not do this, so we have less testing on the things that matter for
> > the next release.
> 
> Disallowing "stable unstable" uploads has a very small effect on this.

That's arguable, and not technically founded. However, allowing
stable/unstable uploads implicitly allows this to happen. So if we
enforce this in the long run, as you suggest, we will have to stop
stable/unstable uploads anyway.

> > > In any case, I don't see why we should be discussing what technical merits
> > > there are in these uploads, but what technical merits exist in disallowing
> > > them as I haven't seen any of those which are valid either.
> > 
> > I've already covered those, but you have blown them all off. I don't see
> 
> That's exactly my feeling as well, except the other way around.
> 
> > how you can argue against them. Those problems exist for a majority of
> > the uploads that would be done for stable/unstable. Just because the
> > problems don't affect a few possibilities, does not give merit to
> > allowing such things, it just means they don't have problems. Nothing
> > good comes from doing a stable/unstable upload.
> 
> The problem is that the bad things which come from it are not due to the
> fact that they are "stable unstable" uploads.

Of course they are. It means the packages have to be compiled on stable
and uploaded to unstable. It means there is no way around that, and
problems do occur because of it. By disallowing them, we are a step
toward enforcing same dist compile/upload. Even if we skip this step, it
will eventully come to pass anyway, since you can't enforce that without
disallowing stable/unstable uploads.

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Herbert Xu]

On Wed, Mar 21, 2001 at 04:35:58PM -0500, Ben Collins wrote:
> 
> > > 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.
> 
> And side affects are often bad, as they have unforseen problems.

Are you saying that packages compiled against old libc6-dev packages are
not guarranteed to work with a new libc6? Well, better tell that to all
the application vendors out there.

> against stable. Yes bug reports can do this. However, when you upload a
> package built against stable, the buildd's use unstable, so now you have
> feature skew across architectures. That is a bad thing.

Here's the crux of your current problem.  The buildd is broken.  In your
original message, you actually said that the buildd should build on stable
for such uploads, which would be the correct thing.

> Also, we want our latest features to be tested. Compiling against stable
> does not do this, so we have less testing on the things that matter for
> the next release.

Disallowing "stable unstable" uploads has a very small effect on this.

> > In any case, I don't see why we should be discussing what technical merits
> > there are in these uploads, but what technical merits exist in disallowing
> > them as I haven't seen any of those which are valid either.
> 
> I've already covered those, but you have blown them all off. I don't see

That's exactly my feeling as well, except the other way around.

> how you can argue against them. Those problems exist for a majority of
> the uploads that would be done for stable/unstable. Just because the
> problems don't affect a few possibilities, does not give merit to
> allowing such things, it just means they don't have problems. Nothing
> good comes from doing a stable/unstable upload.

The problem is that the bad things which come from it are not due to the
fact that they are "stable unstable" uploads.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Ben Collins]

On Thu, Mar 22, 2001 at 08:22:40AM +1100, Herbert Xu wrote:
> 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.

Sorry, but allowing stable/unstable uploads is not a social problem, it
is a technical one.

> > 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.

And side affects are often bad, as they have unforseen problems.

> > 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 and it hasn't been built with LFS, file a
> bug report.  If a package uses obsolete db packages, file a bug report.
> 
> Disallowing "stable unstable" uploads will *not* solve this problem.

But a maintainer may not know about this, and this is just speaking of
libc6. There are many packages that may configure to use newer
interfaces in libraries in unstable, that are not done when compiled
against stable. Yes bug reports can do this. However, when you upload a
package built against stable, the buildd's use unstable, so now you have
feature skew across architectures. That is a bad thing.

Also, we want our latest features to be tested. Compiling against stable
does not do this, so we have less testing on the things that matter for
the next release.

> > 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.
> 
> Obviously you disagree with me about what is a technical merit.  IMHO,
> testing ABI compatibility of libraries like libc6 is aa technical merit.

But it is not one that should be solved by allowing stable/unstable
uploads. If you want to do that, just upload to unstable (which is bad,
as I have already noted above).

> In any case, I don't see why we should be discussing what technical merits
> there are in these uploads, but what technical merits exist in disallowing
> them as I haven't seen any of those which are valid either.

I've already covered those, but you have blown them all off. I don't see
how you can argue against them. Those problems exist for a majority of
the uploads that would be done for stable/unstable. Just because the
problems don't affect a few possibilities, does not give merit to
allowing such things, it just means they don't have problems. Nothing
good comes from doing a stable/unstable upload.

Ben

-- 
 ---===-=-==-=---==-=--
/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Herbert Xu]

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 and it hasn't been built with LFS, file a
bug report.  If a package uses obsolete db packages, file a bug report.

Disallowing "stable unstable" uploads will *not* solve this problem.

> 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.

But why not? If there's no other reason (all the ones you've listed can
already be solved by bug reports against the relevant packages and won't
be solved by doing this anyway), compiling it on stable is just as good as
compiling it on unstable.  In fact, I still contend that it is better
because you are aactually testing whether the libraries involved are
compatible or not.

> > 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.

Well that's where our opinions differ.  My perception is that not only
doesn't this solve a large proportion of those problem cases, it also has
the nasty side effect that maintainers of packages where your concerns do
not stand will be wasting time recompiling packages.

> 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.

Obviously you disagree with me about what is a technical merit.  IMHO,
testing ABI compatibility of libraries like libc6 is aa technical merit.

In any case, I don't see why we should be discussing what technical merits
there are in these uploads, but what technical merits exist in disallowing
them as I haven't seen any of those which are valid either.
-- 
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Ben Collins]

On Thu, Mar 22, 2001 at 07:45:27AM +1100, Herbert Xu wrote:
> Ben Collins <[EMAIL PROTECTED]> 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   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Herbert Xu]

Ben Collins <[EMAIL PROTECTED]> 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~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#90511: proposal] addressing objections (re: disallow multi-distribution uploads)

[Ben Collins]

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   \
`  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  --  [EMAIL PROTECTED]  '
 `---=--===-=-=-=-===-==---=--=---'