On Mon, 2019-02-18 at 14:16:56 +0100, Chris Lamb wrote:
> > The problem with emitting this tag unconditionally, even within the
> > Debian-vendor realm, is that people create local packages for their
> > own, or for $work, etc.
> Hmm. Emitting such a tag here still seems right to me, or at least
> when balanced with the downsides. The local package will never
> reach "dak prime" by definition, after all, and the maintainer can
> simply override the warning if they so wish (and do not use a
> vendor).

The problem with this is that a warning (now) or a non-overridable
error (in the future) are rather scary looking, and even harder to
override as the latter does require a custom vendor profile. :(
Something like the following untested one:

  Profile: vendor/main
  Extends: debian/main

Which would of course still trigger on other systems w/o that vendor

This is compounded with the fact that there's still no clear
distinction between what is the core specification of the packaging
system and what's (possibly arbitrary) Debian-specific policy (which
I'm trying to fix slowly from the dpkg side by documenting the first
part within dpkg itself, but still), and that the tag description does
not help either as it seems misleading to me. :/

> > in most cases will not go to the trouble of creating a new vendor for this.
> I wonder if part of the solution might be to make this bit easier?

Creating the profiles is rather easy, the above would be a simple
example of that, and can be placed either system-wide or on each
user's home. The problem is that this needs to be deployed on each
user/CI/build system that is going to have to deal with those. That's
why I think the "presence" of the tag is inverted here, for something
that really feels should only be emitted within the confines of the
Debian (and Ubuntu) archives.

> Or perhaps not emit this tag for "local" packages (via the
> versioning scheme?)

I'm not sure there's any reliable way to distinguish those? I think
most people even tend to use the defaul target distribution from dch,
and use normal looking versions for local packages. But maybe you had
something else in mind?


Reply via email to