[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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



Reply to: