Re: when can a package be made architecture-dependent?
Adam DiCarlo <aph@debian.org> writes:
> "Steven G. Johnson" <stevenj@ab-initio.mit.edu> writes:
>
>> 2. Don't set architecture to a value other than ``all'' or ``any''
>> unless the upstream package is intrinsically unportable
>> (e.g. a program to disable a Pentium CPU ID). If the package
>> is theoretically portable, even if it currently fails to build on
>> some architectures, it should be set to architecture any/all to
>> open a path for future porters. Setting your architecture to
>> ``i386'' is usually incorrect.
> But I do think this goes too far. There might be good reasons why the
> upstream maintainers or debian maintainers are unable to maintain a
> ported package --
Well, I have been trying to think of some of these reasons.
> notably, if the upstream were not willing to take patches for
> building in other architectures.
If upstream is unwilling to take patches to improve software,
we do have the ability to maintain a set of diffs. Indeed, our
social contract does seem to imply this.
> OTOH -- I do agree in principle.
Cool.
I suppose it comes down to what ones image of a Debian
developer is.
Is a developer merely a glorified packager, who mechanically
packages software, and shuffles off problems with the package
blindly upstream? I hope not, and I have long rejected this narrow
view of what a developer is.
I see a developer as an active participant in the improvement
of the software they maintain (we are maintainers, after all, not
packagers); who actively ensure the package integrates into the
Debian system. In the early days of the FSSTND,there was a lot of
work done to modify packages to fit the file system, and in several
cases far in advance of the upstreams willinglness to accept the
changes (I struggled with LaTeX2HTML for years).
A maintainer has always made changes, accepted by upstream or
not, to integrate the software into the set of Debian standards.
As a project, we seem to have committed to supporting
multiple architectures. As maintainers, this means that we be
willing to accept modifications from our fellow developers working
on other arches (note I do not presuppose that all maintainers be
able and willing to port things to all 11 arches single handedly).
Indeed, I doubt if *ANY* upstream authors really have access to 11
architectures, and test on them, with the exception of perhaps the
Linux kernel; the fact that we have 11 supported arches is because
the Debian project stood up to be counted.
Agreeing in principle, though nice, is irrelevant unless the
nitty gritty underpinning of that decision are also respected. And
that includes giving all architectures a chance at running the
software you maintain.
manoj
--
DYSLEXICS OF THE WORLD, UNTIE!
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: