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

Re: Bug#1007717: Draft resolution for "Native source package format with non-native version"



Christoph Berg writes ("Re: Bug#1007717: Draft resolution for "Native source package format with non-native version""):
> Re: Lucas Nussbaum
> > 4c. We believe that there are indeed circumstances in which
> >     1.0-with-diff is the best choice for a particular source package,
> >     including, but not limited to, git-first packaging workflows.
> >     However, we recommend discontinuing use of 1.0-with-diff in other
> >     circumstances to gain more uniformity.
...
> The bit I was missing is something like "we would welcome changes to
> the 3.0 format to make it usable for the remaining cases where 1.0 is
> still better today". Did anyone investigate if that would be feasible?

A format that solves this problem well is entirely feasible on a
technical level, and not even particularly difficult.

Contenders for the details that have been mentioned in this thread[1]
are 3.0-with-git-diff (#1007781) and Lucas's suggestion for
incremental tarballs in this conversation
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007717#185).

That could certainly fit within "changes to 3.0" since 3.0 already
encompasses a very wide variety of formats.

The real diifficulty isn't technical.  It's that it isn't worth
anyone's time *implementing* it because of the strong possibility that
its support and deployment would be blocked.

Perhaps TC would be willing to say something like this

   We hope for the development of a version of the 3.0 format which is
   usable for the remaining cases where 1.0 is still better today.

   The "3.0 with git diff" proposal in #1007781 seems to us to be a
   good option, and we encourage its implementation.  If the
   implementation quality is good, we feel it should be supported
   within Debian (subject to an appropriate transition plan).

I think 3.0-with-git-diff is the most promising candidate because it
fits into the existing ftpmaster workflow exactly as 1.0-with-diff
does now; this isn't so true of Lucas's incremental tarballs, and it
is even less true of my earlier 3.0-with-rsync-delta.

If the TC wants to give its blessing to one of the other format
proposals then that would be fine too from my point of view, but my
personal feeling is that it would be setting the TC up for a fight
with ftpmaster.  From what I know of the ftpmaster workflow I think
even Lucas's incremental tarball proposal would be a retrograde step
for them.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.


Reply to: