Bug#90511: proposal] disallow multi-distribution uploads
On Thu, Mar 22, 2001 at 09:00:02PM +1100, Herbert Xu wrote:
> Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de> wrote:
> >
> > IMHO, the fundamental and unavoidable reason why we have this problem
> > is the following:
>
> > We don't know in which Packages files (=distributions) a
> > single binary is (used or) going to be used.
>
> Perhaps I'm missing something, but I thought the whole point of having all
> these dependencies is so that as long as all of them are satisfied, that
> the package continues to work. If that's not the case, I think we better
> pack up and go home :)
Well, yes. If you leave aside that the dependencies don't always tell the
whole truth, the point is that the dependencies can be different depending
on your build environment (considering libraries). I think one point for
testing to wait for a widely available version is to not have entirely
different trees because of different libraries.
This is one of Bens points in disguise (maybe my whole argument was just the
generalization of Bens others points). If you compile on unstable for
"stable unstable", you might suck in newer libraries. If you compile on
stable, you might stick with older libraries even on unstable.
The package depends on the build environment (not only in its dependencies,
but probably also in file locations etc), and we need to choose the
build environment depending on the distributions the package is going to be
used on (or not). In all its generality, this is a difficult problem.
But for packages like your kernel packages, this is of no concern.
So if we stick with the possibility "stable unstable" for packages where
the *build environment* can be either a stable or unstable machine, and
where the resulting packages are fine in stable (wrt stability) and unstable
(wrt cutting the edge), then I think this is perfectly ok. I am now
realizing that I am making a new point here, and I have to think about it,
but it seems that this could probably mean that we have to look at the
(factual) build dependencies.
To summarize: I see no problem with allowing "stable unstable" uploads for
packages which work the same regardless where they are built on (this
includes version of debhelper, libraries etc). This seems to be a quite
strict requirement, stricter than it used to be, I think.
> > This is a source for conflicts and inconsistencies, because whenever you
> > want to compile something you have to make sure it will be okay for all
> > distributions it is going to be used in. As this includes decisions made in
> > the future[1], there are potential problems you can't address.
>
> Well my position is that the people in future should make accomodations for
> you. This is what compatibility is all about. If a library changes its
> ABI, then it must change its soname (or at least their package name) so it
> doesn't break old binaries. Other things should also act accordingly.
There are more subtle problems here than library apis. For example, I had a
package which could be built on stable, but not on unstable, because the
behaviour of strip changed. Or debhelper installed docs into the new place
and a hard coded path in the rules files broke. If all these are considered,
I agree with you. But as I said above, this issue has a strong relation to
build environments and build dependencies.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: