[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1007717: Native source package format with non-native version

Dear TC,
I cannot speak for what Ian wants,
but I would also like to formally ask the TC to rule on this issue.
My hope is that what Ian and I are asking for is similar enough that the
TC can consider the issues together.

Specifically, I'd like to ask the TC to come up with policy on native
packages and debian revisions using its power under  6.1.1.
In particular I ask the TC to consider the hypothesis that:

* Debian revisions are useful when there is a separate upstream flow
  from the packaging flow.  For example when Debian versions are
  released at different times than upstream times, Debian versions have
  different content (for example a debian directory), or Debian versions
  are maintained by different people.  IN these cases a debian revision
  may be useful.

* Native source package formats (1.0 tar only and 3.0 (native)) are
  useful when the work flow
  is easier to maintain without separated Debian changes.  There are
  several cases involving git work flows where package maintenance is
  improved by not requiring this separation.

* Git work flows are a best practice.  There may be other best practices
  too.  We want to encourage git work flows to become more streamlined
  and easier; when people have found git work flows that make their job
  as maintainers easier, we want to encourage that.

I don't think the TC needs to do out-of-charter design work to come up
with policy in this regard.
I think there's been a lot of work within debian-policy, within
discussions of git packaging flows, and within the  consensus-seeking
discussions run over the years.

I'll point outt that the behavior of non-experimental package
building tools explicitly falls under 6.1.1 and does not require the TC
to override a maintainer.

I believe it is also appropriate for the TC to rule under 6.1.2.
It's clear that policy, the packaging tools, archive build tools, and
tools to support git work flows need to be in harmony for things to work
It's clear there is overlap, and it is clear to me we do not have
harmony today.

I'd also like to provide some initial briefing material to the TC to
help you all come up to speend on this issue.

* Ian's mail that you were forwarded

* #bug 737634

   * My messages starting at
     and following the thread.  I explain one case where you want to use
     a debian revision with native packages.  I think Ian has described
     cases that are more clearly directly related to the Debian archive,
     but I clearly outline in that bug report problems I was having and
     why proposed alternatives did not work.

* Around that time  a claim was made that debian-policy did not permit
  debian revisions with native packages.  I challenged that claim and in
  https://lists.debian.org/8761otp2r1.fsf@windlord.stanford.edu Russ
  acknowledges that the section of policy he was pointing at did not
  actually forbid debian revisions with native packages.  So at the time
  dpkg made the change it was breaking things and there was no policy
  requirement for the change.

* Ubuntu had to make a change to dpkg-source at least as used by
  launchpad for recipe builds to continue to work.  I don't know if they
  still maintain that patch, but it seems like a bad sign when a major
  downstream needs to revert a change  we've done to get work done.  It
  would perhaps be valuable to look into whether they still have that
  delta and if not how they work around things.

* https://lists.debian.org/tsla738bpwz.fsf@suchdamage.org the most
  interesting bit there is a consensus of the project that if your
  upstream uses git, best practice is for your packaging to use git.

* https://lists.debian.org/tslr252ioa3.fsf_-_@suchdamage.org Consensus:
  native packages are sometimes an appropriate tool to use in contrast
  to earlier consensus that we wanted to move away from them.

* Plus the recent thread on debian-devel.

* The git packaging BOF at DebConf19.

Thanks for your consideration,


Attachment: signature.asc
Description: PGP signature

Reply to: