Hi, On Thu, 2024-06-20 at 08:19 +0200, Philip Hands wrote: > 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 we are talking about hypothetical ways upstream might nudge you into: there is a large territory that requires arbitrary code execution as build time (say to instatiate d/control from a template) which neither proposal for tag2upload allows. So with that choice, you would stick to not using tag2upload no matter which variant being discussed would be deployed. > If that's the rational choice which any well-informed uploader > will adopt, then such a limited tag2upload really serves no purpose. And if that's the rational choice any well-informed uploader will adopt, than all variants of tag2upload currently discussed serve no purpose. But if you would use no variant either way, it would seem that either choice (including even no tag2upload at all) would not affect you anyway? Ansgar
