Hi, 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? >>> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-grass-devel mailing list Pkg-grass-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel
