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

a fallacy (was Re: when can a package be made architecture-dependent?)

"Steven G. Johnson" <stevenj@ab-initio.mit.edu> writes:

> He (Ron Lee <ron@debian.org>) responded:
> > I can quite sympathise with what you want, but I'm not going to
> > make this package arch-any just so it can break on every arch
> > except i386 (and hence keep it out of testing for everyone).
> > That's not the sort of equality we're aiming for.
> Actually, I thought that *was* the sort of equality Debian was aiming
> for...if it breaks for any architecture, it's a serious problem that
> everyone has to deal with.  If every Debian developer refused to support
> architectures he/she didn't have immediate access to, non-x86 Debian would
> disappear pretty quickly.

I really don't understand this.  The maintainers of the software the
the upstream folks who provide the software.  The Debian maintainer is
not a porter for the software or the maintainer.

If the upstream software maintainers state they don't want to support
certain architectures, what the hell, isn't that their perogative?  

Are we in some sort of inverted fascist world where just because an
author gives away some software, she's suddenly required to commit to
supporting whatever we say?  Remember, supporting different
architectures can be a bear of a job.

I mean, believe me, I agree in principle regarding the equal stress
Debian itself should place on the different architectures, but I don't
think it's reasonable Debian developers be forced to perform
architecture maintenance duties that the upstream maintainer refuse to
support.  I'll go even further and say I will strenuously object with
any policy statements that force Debian developers to fork packages
beyond what we're already doing for package integration.

And if you don't like it, volunteer with the upstream maintainer to be
a port maintainer for the software, and do the work.

In short, this is between you as a PowerPC user/hacker, and the
upstream maintainers.

...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>

Reply to: