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