Simon McVittie writes ("Re: Standardizing the layout of git packaging
repositories"):
> [stuff]
Thanks for this helpful survey.
> dgit
> ----
>
> dgit encourages the answer to be "exactly the source that will be built,
> vendor patches *are* applied, if the package uses 3.0 (quilt) then .pc
> also exists and reflects the state of the tree". I'm not sure what
> techniques dgit users use to deal with non-native packages that have
> vendor patches without rebasing a published branch - git-dpm seems like
> it might be a good fit?
I am planning to have dgit do some git-dpm'ish things, probably
actually using git-dpm.
The result will be that the master branch has the same tree contents
as currently, but that for a `3.0 (quilt)' package the history will
have a more useful structure.
> There seems to be a strong correlation between happy dgit users, and
> those who either only do native packages (hello joeyh) or consider 3.0
> (quilt) to be an abomination and are sticking with source format 1.0
> (hello iwj); so the .pc thing might not matter to these users in
> practice, but is significant do those who do want 3.0 (quilt).
If you don't care about exactly what appears in the `3.0 (quilt)'
patch structure then dgit does work well. So cases where it is
currently excellent are:
* Debian native packages
* NMUing a `1.0' package
* Locally modified packages, managed in git
For NMUing a `3.0 (quilt)' package, dgit complies with the current
rules as set out in the various manuals, but doesn't do as good a job
as iti can. I did an NMU of a Perl package with it and had some
grumbling from the Perl team. (Which ultimately discouraged me from
doing some useful work there.)
So based on feedback, and thinking about it: dgit needs to have better
bidirectional gatewaying between the git and quilt worlds. #720177 is
the related bug, which I have BCC'd because my most recent previous
message there doesn't reflect my current thinking.
> If being VCS-agnostic is valued, it might be an interesting exercise to
> design a source package format that is meant to work well with sources
> in a dgit-style DVCS (e.g. avoiding clutter like .pc/ when unpacked),
> but does not specifically rely on git concepts and formats.
Personally, I think this is a waste of time. git's UI is appalling
but it is by far the most capable VCS in existence. Attempting to
cater to the lowest common denominator will be crippling for any new
tool or approach.
> Alternatively, perhaps it's time for a 4.0 (git) source format to become
> a reality, if someone cleverer than me can devise a way to avoid it
> containing the full history (which would not be feasible for ftp-masters
> to review, and is reasonably likely to contain accidental sourceless or
> non-free files).
This is certainly a possibility. I think dgit is going in the right
direction.
Will you be at Debconf ? I'm hoping to have some more handwaving
etc. about this kind of thing there.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21492.40953.87595.162...@chiark.greenend.org.uk
