Re: when can a package be made architecture-dependent?
Manoj Srivastava <srivasta@debian.org> writes:
> 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.
Ahem, that is a strawman if ever I saw one. :)
> 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.
Of course.
> A maintainer has always made changes, accepted by upstream or
> not, to integrate the software into the set of Debian standards.
That is her duty, yes.
> 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.
That's a fine point, but see below for some cases of exceptions.
> 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.
Well, I guess I keep coming back to the example of the unportable
software. This is the software rather mentioned in the DDR passage
cited -- it has serious technical reasons why it's only available for
a given port.
I think we all agree there's a line somewhere, a fuzzy line, on what
ought to be arch = any and what should be restricted.
Lets get down to cases in the hopes that it will help us refine the
principle underlying where this line generally is to be found.
* jade
A package I used to maintain; rather non-portable C++ when I had it.
Dead upstream. I elected to set arch = any because I thought it was
important for all arches to have this so they could build SGML/XML
documentation. I didn't have to do the porting, but I did have to
integrate patches -- and it wasn't very fun. But that was my choice,
fine. The porters were very kind and sent patches, I integrated them,
and later someone more knowledgable in C++ took over the package, it's
now available for all arches. Success story.
Is there a principle to arch any here? I guess I would argue that
jade was dead upstream and wasn't really inherently unportable -- it
just had some character width assumptions and build problems with
other arches. So if there's a principled answer, I guess it would be
that I would say that just because the software has some 32-bit vs
64-bit int problems, that doesn't mean it has deep inherent porting
issues, and thus it should be ported.
* cmucl
Inherently unportable (the underlying engine that translates lisp to
assembly code, called "python", is very unportable, is not even in
ANSI C). Moreover, the porting effort for this has forked into a
different project, SBCL.
Current Debian package is Architecture: any. I think this is
questionable. This will always only be available for i386. I think
it's worthwhile to have the architecture line reflect this so the
porters don't see this as a pending problem. Of course, they probably
already ignore this one.
* sbcl
A fork of cmucl rewritting in ANSI C and reworked to be more portable.
Even so, requires *serious* effort to port to different CPU
instruction sets.
Current Arch line:
Architecture: alpha i386 sparc powerpc mips mipsel
In this case, you see, the maintainer is tracking the set of ports
explicitly supported upstream, until upstream adds support for the
other arches.
I think this is fine. The maintainer is basically telling users of
the 'ARM' arch, e.g., to work with upstream to get patches integrated
if they want to see this supported.
I think it would also be fine to set Architecture: any, in the
expectation that sbcl will eventually support all architectures.
I'll hold off on any conclusion with this until people respond to my
cases here, agreeing or disagreeing with my logic.
--
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>
Reply to: