Maintaining packages in Debian

[Philip Muskovac]

On Tuesday 08 July 2014 17:29:21 Scott Kitterman wrote:
> 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

The scripts already have a sanity check that checks whether the archive changelog is a subset of the bzr changelog
If that check fails the package is skipped and left for manual fixing as the script doesn't know what to do in that case.
(The sync case could be automated by checking for 'ubuntu' in the latest archive version string surely)

The Vcs-* fields are IIRC only there so $RANDOM_OTHER_UBUNTU_DEV knows that he should please commit his change into the bzr repo so the changelog diff I just mentioned doesn't happen. Nothing on the technical side requires them.

What we do need is versioned build-depends on any build-dep that is handled by kde-sc-dev-latest. Debian has unversioned deps for some of them I believe (or at least had in the past) and my regexp in kubuntu-initial-upload does not add any minimal version for unversioned build-deps.
That can cause inconsistencies in the linked lib, so that is a required diff wherever it's there.
Should really be fixed in the script though, patches welcome.

Philip