This is getting off-topic for this bug. But the discussion is interesting. On Fri, 15 Jan 2016, Wouter Verhelst wrote: > My point here (but I'll admit that the above sentence doesn't make that > clear) was that *users* who are familiar with a package on one > architecture should not be surprised by the presence or absence of a > feature on another architecture.
Right. But as a user, I'm even more surprised that the package is missing only on armel... So your point is valid but does not constitute a sufficient reason all alone. The fact that a piece of portable code is not available on armel is also an unexpected surprise, much more so than the lack of a manual page. > > Shall I drop an architecture just because I can't build the manual page > > on that architecture ? > > No. But you shouldn't resort to ugly hacks just to have it build on that > architecture, either. > > Leave your package as-is, pretending that the armel package will build. > The fact that it doesn't should not be your concern as a packager. It's a concern when I run testing on an armel machine. Which is exactly what we do in Kali for example. The packager is also a user... and we aim to have as few regressions as possible in testing. > > My answer is a clear no. > > Policy's answer is a clear yes. (§12.1) I'm sorry, the lack of manual page has never been a ground to drop an architecture from the list of supported architectures. > > I have multiple other options, like moving the > > manual pages to a -doc package which is arch: all. I did not want to do > > this because it would bloat the archive with a tiny little package for a > > possibly temporary solution. > > If the current situation with pandoc truly is a temporary situation, > then the pandoc package will eventually be fixed on armel and your > package will be rebuilt for armel, *without you having to do anything*. That's actually not true since the package has been built for armel already but it has been removed by ftpmasters in the mean time precisely because ghc could not migrate because it was not building on armel... > In order for this decision to be made (by the porters and the release > team), it is imperative that they have a good understanding of the state > of the architecture. If everyone were to work around the "some part of > my package doesn't build" problem in the way that you're suggesting, > then the end result will be that release team members and porters who > look at an architecture will see that 95% of packages are built for that > architecture (thereby assuming the architecture is in good shape), > whereas the reality will be that 95% of packages are built, but half of > those have special-cased the architecture and are basically not > functional. What if I actually prefer that armel is not dropped and I want to support my package on armel even though the architecture has some restrictions? > Additionally, past experience as a porter for a struggling architecture > tells me that it is useful to look at reverse dependencies to prioritize > which packages to get to work on your architecture again. By bypassing > things in the way you are, you hide information from the porters, > thereby making it more likely that the current "temporary" situation may > not be so temporary after all. I'm not hiding anything... as a porter you can check build dependencies which are specifically excluded for armel... And basically I don't need a porter to look at this package, the porter can concentrate his effort on the missing packages... and the package maintainer will at some point notice that pandoc is back... and will be glad to be able to clean up the old hack. > If the lack of an armel build is interfering with the migration of your > package to testing, then file a bug against ftp.debian.org (RoM, build > dependencies no longer available on architecture) or release.debian.org > (to request that the architecture in question be ignored for the > purposes of testing migration). Actually, this requirement is precisely what created all this mess. All the required packages were available but ghc was FTBFS on armel. And since the ghc maintainers wanted to transition it to testing, they asked to remove the binary from armel. And the ftpmasters dropped all the armel builds of all the packages that had ghc in their reverse build-depends tree. > Don't try to game the system. I don't see how trying to support a package as best as I can is gaming the system. There's no policy rule that imposes that all architectures have the same level of "support" in a given package. Otherwise we would never introduce new architectures and we would have to drop old architectures much more quickly... That said I agree that uniformity across architectures is better. But even though you believe the situation to be clear cut, I still stand that there's room for the maintainer to put multiple aspects in balance. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
