Re: When the compiler just can't cut it....
On Tue, 2002-02-26 at 23:20, Camm Maguire wrote:
> 1) How far should one push compilation efforts before determining
> that a package just won't build on a particular machine?
It's entirely up to you. Debian maintainers aren't obliged to make any
heroic efforts to port their packages to previously unsupported
platforms.
> 2) If a package has integrity tests which the build fails in a
> serious way, is it better to ship a buggy lib or pronounce the
> package un-buildable on said machine?
Again, you have to make a value judgement. Clearly there is no point
shipping a package that is so broken as to be useless - it sounds like
the ia64 lapack is in this situation for example.
> 3) And how does one prevent such a situation from generating
> release critical bugs on the package threatening to remove it
> from the arches on which it *does* compile perfectly? I.e.,
> does the maintainer have the discretion to fill in the
> Architecture: field as she sees fit, excluding the problem
> cases and essentially giving up on them? I've noticed that
> the autobuilders will try to build everything regardless of
> Architecture: field.
Firstly, failure to build on a particular architecture is not a
release-critical issue unless that architecture already has an older
version of the package in testing. So, assuming the situation with your
packages hasn't been actively getting worse, you should have no
problem. If a package no longer builds for an architecture that used to
work, and you think there is no realistic prospect of it getting fixed,
you can ask ftpmaster to remove the old binaries from the archive which
will again prevent it from being a release blocker.
That aside, yes, it is perfectly respectable for you as the maintainer
to take a view on which architectures you think ought to be supported
and set the Architecture: field appropriately. Once a particular
architecture is excluded, its autobuilders will tend to lose interest in
that package and won't attempt to build future versions even if you
later change the Architecture: field to be more permissive. So, again,
this is most appropriate if the package is fundamentally unable to be
used on that architecture, rather than just because of some temporary
toolchain problem.
p.
Reply to: