Russ Allbery <rra@debian.org> writes: ... > At the risk of trying to argue by analogy, it feels akin to saying "okay, > you can have a binary buildd, but only if it doesn't use a compiler and > only copies files around." Yes, that's a compromise compared to no binary > buildds, but in a way that makes the whole picture more complicated and > doesn't achieve the point of the design. Also, packages change over time. If one had that restriction, and got used to being allowed to use that sort of restricted buildd, what happens when upstream adds something that needs compilation? Similarly, if one has a package that could be dealt with by a limited tag2upload, and then upstream changed something that nudged you into the problematic territory, you'll be confronted with having to abandon tag2upload, or perhaps having to start doing trickery to live within the limitations (e.g. performing the problematic steps and then committing the results of that to git, say, which will just make the package horrible). If that's the choice available, I'll be sticking with local dgit from the start, because at least that's going to be able to deal with tomorrow's version from upstream. If that's the rational choice which any well-informed uploader will adopt, then such a limited tag2upload really serves no purpose. Cheers, Phil. -- Philip Hands -- https://hands.com/~phil
Attachment:
signature.asc
Description: PGP signature