Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On 13/11/14 14:04, Ron wrote:
> I really do think that the names of the branches are actually going to
> be the least of your worries here, unfortunately. Even with a naming
> scheme that's widely adopted, things just aren't going to be that sort
> of uniform outside of (a fairly large number of) fairly small subsets.
I agree that the expected contents of the branches are far more
important than their names. Unfortunately, while acting as "the Debian
expert" for Debian derivatives at $day_job, I keep finding that the
answer to "OK, I've cloned a package's git repository, I know what code
change I want, now do I change the upstream source or drop a patch into
debian/patches or what?" is "... I can't actually answer that until you
tell me which source package you're working on".
At the moment, I suspect Kali's approach - arbitrarily choosing one of
the popular approaches, only cloning packaging repositories from Debian
that happen to match that approach, and restarting a new packaging
repository for those that do not - is likely to be the only viable
solution to that. There's always going to be a certain amount of
re-importing in any case, because some packages in Debian are maintained
in a non-git VCS or in no VCS at all; but it's easier to inspect history
if it's possible to clone the existing packaging repository for "most"
Debian packages of interest.
One of my projects for the near future is to put together some simple
test-cases for packaging - a set of simple projects with a downstream
patch that gets applied in the next upstream release, a downstream patch
that doesn't get applied upstream, and a downstream patch that conflicts
with upstream changes - and try packaging them with each of gbp-pq,
git-dpm and gitpkg. To have the complete set, I think I need one project
where the upstream tarball is a simple git-archive of the upstream git
repository, one where the upstream tarball has extra detritus (e.g.
Autotools) and/or missing files (upstream's .gitignore not being in the
tarball is also common in Autotools), and one where the Debian
maintainer needs to filter out a non-free file. Anything else you can
think of?
S
Reply to: