Re: binary-alpha and binary-sparc directories
(Crosspost to -alpha and -sparc removed.)
Bill Mitchell writes ("Re: binary-alpha and binary-sparc directories"):
> It seems that the Guidelines document needs updating to address
> issues falling out of this.
>
> One issue is whether binary packages are to be distinguished by
> distribution-specific naming convention (and, if so, what that
> convention is to be). Binary packages will need need distinguishing
> names if they're to be uploaded to a common Incoming directory.
As Matt Bailey suggests, I think separate Incoming directories is a
better solution.
If we encode the architecture into the filename it will become
excessively long, and directory listings will contain much useless
junk.
> Will debian systems offer cross-compilation facilities? Will
> the developer of a sparc-targeted package be expected to provide
> an i386 build as well? If not, and some other developer provides
> the i386-targeted package, which of the two source packages (which
> may differ from one another) will be in the distribution?
Debian packages can't (in general) be cross-compiled for different
architectures. We can't make a requirement that this should be
possible, because not all upstream source could be made to meet it.
I expect that most packages would have a `primary' Debian maintainer,
and that people doing ports would just upload binaries. If they need
to make changes to the source they will have to work closely with the
`primary' maintainer to ensure that all the sources are kept in step.
> It seems to me that packages will need a primary maintainer, who
> would be responsible for the source package, and an architecture
> specific maintainer for each supported binary package. One person
> could act in all capacities, of course, but I'd expect that at least
> some packages would have different maintainers for the different
> architectures.
>
> The way I see this working, architecture-specific maintainers with
> the ability to address architecture-specific bug reports and do
> architecture-specific testing would feed architecture-specific
> fixes and patches to the primary package maintainer. Primary
> package maintainers having, say, a sparc would install alpha
> or i386 patches blindly, relying on the testing done by the
> alpha and i386 maintainers, and issue a package revision update.
Yes.
Ian.
Reply to: