Maintaining packages in Debian

[Scott Kitterman]

On Tuesday, July 08, 2014 20:45:14 Harald Sitter wrote:
> 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?

I've never seen one in a source package.  

If we would script the case when someone forgets to commit to bzr, that same 
automation would cover the case when we sync'ed from Debian.  With SOOOOOO 
many packages, I want this to get easier.

Scott K