Bug#893188: mapnik: add mips* back to arch list

James Cowgill jcowgill at debian.org
Tue Mar 20 10:53:57 UTC 2018


Hi,

On 18/03/18 09:37, YunQiang Su wrote:
> On Sun, Mar 18, 2018 at 5:05 PM, Sebastiaan Couwenberg
> <sebastic at xs4all.nl> wrote:
>> On 03/18/2018 09:23 AM, YunQiang Su wrote:
>>> On Sat, Mar 17, 2018 at 5:41 PM, Sebastiaan Couwenberg wrote:
>>>> Why do you want mapnik back on mips*?
>>>>
>>>> I don't expect any actual users of the mapnik family of packages on
>>>> mips*, so despite improvements to the architecture in Debian I don't
>>>> think it's worth the effort.

How much extra effort is required here?

>>> At least Loongson may need it, as Loongson is working on providing
>>> high-end PC/Server in China, and some department of government and
>>> some companies will need it.
>>> At least please provide mips64el and mips64r6el, both of them are
>>> targeting for high-end machines.
>>
>> If they "may" need it, I strongly prefer those users who will actually
>> use mapnik on mips* to request it. So far it's still hypothetical.
> 
> In deed, a Loongson guy told me that their customers are using mapnik.
> He didn't tell me the customers of course.
> 
> @Anibal, @Douglas,
>    I guess we should also ask for any our customers are using it.
> 
> @Sebastiaan, I know it is a quite hard work to maintain so many packages,
> and before the response from MIPS is some slow, I am very sorry of that.
> Anyway, we can have a quicker response in future.
> 
>> I'm inclined to close this as wontfix until actual users of mapnik
>> request it on mips64el.

Debian policy lists the two valid reasons for restricting the
architecture list (5.6.8):
- A package is not portable to that arch.
- A package would not be useful on that arch.

I argue that none of these reasons apply here and therefore the packages
should be Architecture: any (or possibly linux-any, but I haven't
checked non-linux arches). This would also assist ia64 which I notice is
not in the architecture list. Also note that none of these reasons
require actual users. Do you think there are users of mapnik on every
architecture you currently have in the architecture list? Can you
provide the requests from users of these architectures to enable mapnik?

If you are concerned about mips (or any architecture) blocking testing
migration then the two correct options are:
- Asking the porters for help.
- Requesting removal of your package on that architecture.

Sometimes the porters have a lot of other work to do or are unavailable.
Sorry if this has happened to you.

The advantage of requesting removal over restricting the arch list is
that the package automatically becomes available again if it gets fixed
(eg by upstream) and the package is continually built and tested each
upload so people can see what is broken. Not restricting the
architecture list avoids porters having to poke maintainers when a new
architecture is bootstrapped.

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-grass-devel/attachments/20180320/ea7caf47/attachment.sig>


More information about the Pkg-grass-devel mailing list