Re: How should we deal with 'pointless-on-this-arch' packages?
"Roberto C. Sanchez" <email@example.com> writes:
> On Sat, Oct 14, 2006 at 07:30:15PM +0200, Holger Levsen wrote:
>> Isn't it up to the maintainer to say $package is not suited for $architecture?
>> And aren't maintainers happy to receive hints (e.g. from porters or users of
>> a certain package), which specific package is not suited for a specific
> I would think that by definition a user of a package is the last person
> who would be qualified to make a determinitation as to whether a
> particular pacakge is suitable for a particular architecture.
I think that the maintainer is qualified saying "This source can't
support an arch. Porting/maintaining the stuff is too difficult."
The proters are probably qualified saying "This package is insane,
nobody in his/her right mind will want to run this." E.g. the arch
just lacks the hardware and processing power to run a realtime 3D
game. The porters should also be the best judge about lack of speed
on the buildds.
A user is qualified saying "I want to run this software on my arch. I
can't live without it even if it crawls."
I think it should be in the porters control what packages to build for
an arch with some guidelines what sort of packages can be removed
without loosing release status. For example removing KDE would not be
OK. Removal should be reserved for extreme cases though. Things that
just need long to build should be put into weak_no_auto and limited to
the stronger buildds of an arch.
Maybe someone could come up with a britney patch that would allow an
arch to make a list of package non-blocking for the testing
transition. A package like axiom should not be blocked from testing
because m68k hasn't build it yet. It should be perfectly save to
remove it for m68k till such a time that the buildds catch up. Things
that the porters/maintainer are reasonably sure noone will miss but we
try to build it just in case anyway. I think a lot of the potential
excludes fall under this category.
Just my 2c.