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

[Bas Couwenberg]

On 2018-03-20 11:53, James Cowgill wrote:
> 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?

Updating the Architecture list in debian/control, having to fix 
architecture specific issues when the builds fail on mips*, requesting 
removal of the package and its rdeps from mips* when architecture 
specific issues cannot be fixed.

The first is not a lot of work, the others are.

>>>> 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 consider a package which doesn't have any users on that arch not 
useful.

> 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?

Please don't motivate me to mark all GIS and OSM packages as for amd64 + 
i386 only, which I'm tempted to do whenever I get confronted by 
architecture specific issues.

Those are the only architectures actually used, and in the case of 
mapnik it's most likely not used on i386 either. But i386 is a special 
architecture in britney for which package removals don't unblock testing 
migration.

> 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.

Porters should spend their time on more important packages than mapnik, 
binutils for example (#765710).

Having to deal with issues on mips* is not worth the effort for me. 
Asking the porters for help doesn't seem like a viable option if they 
don't even get around to helping with important toolchain packages. No 
need to put more work on busy people.

Not having mips* in the Architecture list for mapnik saves the effort 
having to ask for removal.

I see no benefit in adding mips* back to the architecture list, it just 
makes my life more miserable having to deal with issues on those 
architectures again.

If there are actual users of mapnik on mips* the added misery may be 
worth the effort in the interest of our users.

Kind Regards,

Bas