Hello world,
What do we think of mixing components? That is, having a source uploaded
to main, say, that has binaries that end up in contrib? Or a program that
can optionally link to openssl and hence builds two binary packages foo
and foo-ssl, one being added to main and the other to non-US/main?
Let's suppose that that sort of situation is desirable for a moment.
The following constraints probably apply:
* binaries including crypto code must be processed outside the US
* all binaries in main should be buildable from sources in main
* all binaries build from a single source should be uploaded at once
So foo and foo-ssl and foo.diff would have to be uploaded to pandora,
from which point foo and foo.diff would want to be moved to the archive
on auric, and foo-ssl installed into the non-US archive on pandora.
Comparably you might upload a game (like ale-clone) to main, that also
has an auxiliary package that's useful but not really necessary that has
to go in contrib because it's, say, an installer package. Autobuilders
don't have to stress about this at all: they can just build the free
package and get a contrib package with no extra stress.
Similarly, you might upload a package, say xacc, to main that builds
xacc.deb (linked against lesstif) for main, and xacc-dmotif for contrib,
and xacc-smotif for non-free. Unlike the previous case this introduces
something of a Build-Dependency on the completely non-free libmotif-dev
for the source package. Perhaps a "Build-Suggests" is what's needed there.
One possibility would be to put the source in contrib, and not have
stable/main/source have all the source necessary to build everything
in stable/main/binary-i386 (or equivalent). I don't think that's
acceptable. Another would be to just build the -smotif and -dmotif debs
if libmotif is available (and a DEB_BUILD_OPTIONS flag is set?), and not
complain if they can't be built. That makes it difficult for the -smotif
and -dmotif debs to be automatically built on architectures that care.
To support all this you probably need to have the following behaviour:
1) good support for manipulating all the binaries on pandora or in
different components or wherever all at once by the name of the
source package
2) uploads to non-US in auric:incoming get rejected with a message
that they have to be uploaded to pandora
3) uploads to the normal debian archive in pandora:incoming need to
be able to be accepted
4) uploads that include any binaries destined for main must
have their sources in main
5) uploads that include any binaries destined for non-US/main
must have their sources in main or non-US/main
6) uploads that include any binaries destined for contrib must
have their sources in main or contrib
7) uploads that include any binaries destined for non-US/contrib
must have their sources in {,non-US/}{main,contrib}
Another question is whether it would be possible to automatically work
out which binaries should be in contrib or non-US where possible. That
is, maintainers would just go ahead and upload packages to main as long
as they're free, and don't directly include any crypto. Some clever
automated scripts then goes along and groups packages together that
can be installed just using main, then just using main,non-US/main,
and dumps the rest in contrib or non-US/contrib.
If we ever want to do this, it probably means we'd have to include
contrib and main in the same directory on the ftp site. One possibility
might be something like:
/pub/debian/pool
non-free/
free/
main -> free
contrib -> free
Automatically moving stuff between components may note be particularly
desirable though. It would probably mean that the non-US/main Packages
file would need to reference files in main on auric, which would be
difficult to arrange (ie, a package uploaded to main is found to depend
on non-US/main and thus should be "distributed" as part of non-US/main
in woody, but not in potato...)
So, probably, we *do* want to supported sources with mixed binaries;
but we probably don't want to allow a .deb to change whether it's in
non-US or in contrib or whatever after it's been uploaded.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgpF76GwvsIAt.pgp
Description: PGP signature