Maintaining packages in Debian

[Harald Sitter]

On Tue, Jul 8, 2014 at 8:28 PM, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Tuesday, July 08, 2014 20:23:50 Harald Sitter wrote:
>> On Tue, Jul 8, 2014 at 3:22 PM, Scott Kitterman <ubuntu at kitterman.com>
> wrote:
>> > The Vcs-foo we need for automation to work, so I have a proposal.
>>
>> First things first... We do? :O
>>
>> AFAIK we have no tooling that relies on those fields but instead
>> everything eitehr does static list iteration or dynamic iteration
>> based on query sets from launchpad API directly.
>
> OK.  I recall it being said that we needed the Vcs-foo so we couldn't sync.
> Personally, I don't see it being worth maintaining a diff over, but with the
> approach we can sync and have the Vcs-foo correct, for whatever reason.

Well, what we do need is the packaging in bzr, whether or not it
contains our Vcs fields has no impact on our automation. That being
said I agree that holding on to a diff just for the Vcs stuff is
nonesense.

I'd really like to hear a use case for the diff to be honest. If there
actually is one that makes it worthwhile to maintain that sort of diff
then the presented solution looks very suitable. If not then I'd
honestly just ditch the diff entirely when there is no actual
packaging delta anymore.
There is a case to be made that the Vcs field should be changed when
uploading an ubuntu version with nothing but a version bump in the
changelog, but without use case I consider that optional at best and
as far as kde core software is concerned the packaging is heavily
batch automated anyway, so we could just flip the values in the
automation.

FWIW, I doubt it would work but in theory debsubstvars (built into
debhelper) could be used as they are generally less intrusive than
control.in, but I think they aren't allowed for source packages as
they wouldn't get subbed in the dsc (IIRC), nevertheless something to
try if you haven't already?

HS