Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
I know the discussion is leaning towards replacing usage of git-dpm with gbp-pq. I have nothing against it but, since we are talking about solutions for a git-centric workflow, has anyone considered the dgit- maint-merge workflow [1]? It is very well documented and would simplify team-packaging policies a good deal. Assuming dgit-maint-merge were widely adopted, packaging policies would only need to cover team-specific details, such as infrastructure or communication channels for sponsorship, and then reference the dgit-maint-merge manpages for the packaging workflow. [1] https://www.mankier.com/7/dgit-maint-merge Best regards, Ghis
Re: Best way to package a python module which is "private" with exposed calling script
Hi Simon, Thank you very much for the response! I've been looking at the offlineimap package on my system (jessie), but in my case `/usr/bin/offlineimap` is _not_ a symlink. Also the python code is not installed to `/usr/share/offlineimap` and instead to `/usr/share/pyshared/offlineimap/` and so if I start a normal interpreter `import offlineimap` does work (which I'd rather it not). Am I completely missing something here or did you possibly mean another example package? Cheers, Thomas P.S. I forgot to subscribe to the list before sending the last email and had to hack in the `In-reply-to` value this time. For any readers, in case I got this wrong this is the post I'm replying to: https://lists.debian.org/debian-python/2017/02/msg00018.html
Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On Tue, 07 Feb 2017 at 10:47:00 +, Ghislain Vaillant wrote:
> I know the discussion is leaning towards replacing usage of git-dpm
> with gbp-pq. I have nothing against it but, since we are talking about
> solutions for a git-centric workflow, has anyone considered the dgit-
> maint-merge workflow?
The dgit-maint-merge man page starts with some axioms:
The workflow makes the following opinionated assumptions:
· Git histories should be the non-linear histories produced by
git-merge(1), preserving all information about divergent
development that was later brought together.
I don't think that is actually a useful model of distro development.
I'm sure the rest of dgit-maint-merge(7) is a perfectly reasonable
workflow when you start from its assumptions, but I think they're
the wrong assumptions.
I think the downstream maintainer job in vendors like Debian (and Red
Hat, etc.) is essentially a rebasing patch series, whether we represent
it like that in git or not:
* we track an upstream version, which we treat as somehow canonical[1]
* we track what the downstream does as divergence from that upstream
version, and only secondarily as a product in its own right (this is
a core assumption in the design of all the non-native dpkg-source
formats, and also SRPMs, so this is clearly something that has been
considered important to downstreams)
* when we import a new upstream version, we adjust our divergence to
apply on top of that new version
* some of the divergence is vendor-specific and we will never upstream it
(for example adjusting paths/defaults to meet Debian Policy)
* some of the divergence is intended to go upstream, although our
upstreams don't always apply in-principle-upstreamable changes
as fast as we'd like them to; when it does get applied, it is often
applied to their current development branch (like a git-cherry-pick)
rather than being merged, and even if we send Github pull requests
or similar, the upstream will want them to be based on some upstream
branch and not on Debian's
* in Debian's case, even if they want to apply all the patches we propose
to their upstream source, our upstreams will never want to `git merge`
the contents of our VCS, because they usually don't want to merge
debian/ (and in fact we actively recommend that they don't)
That's why, although I find dgit an interesting idea, I think
dgit-maint-merge(7) is a trap. If I use dgit at all, it'll be
dgit-maint-gbp(7) or similar.
[Conflict-of-interest disclaimer: I am a happy user of gbp-pq for every
patched package I maintain, except for tap.py and pkg-gnome svn. I would
love to see gbp-pq adopted by DPMT so I can use it for tap.py, and
when pkg-gnome finally moves from svn to git, given the overlap among
active maintainers between pkg-{systemd,utopia,gnome}, I suspect they
are going to use gbp-pq like pkg-systemd and pkg-utopia do.
I also seriously considered maintaining tap.py outside DPMT as a way
to avoid git-dpm.]
Regards,
S
[1] but in most cases not Canonical :-)
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On Feb 07, 2017, at 10:47 AM, Ghislain Vaillant wrote: >I know the discussion is leaning towards replacing usage of git-dpm >with gbp-pq. I have nothing against it but, since we are talking about >solutions for a git-centric workflow, has anyone considered the dgit- >maint-merge workflow [1]? As I understand it, there are a few design choices that make dgit less desirable for this team. The first is that dgit uses single-debian-patch rather than a series of patches as with quilt. The individual patches can be viewed in git but that implies more work for interacting with upstreams and requires the use of the git repo to examine the individual patches, making it harder for non-developers or others outside of Debian to see what we've done to their packages. The second is that dgit prefers to use the upstream git repo but our work is heavily orig-tar based since our main input is PyPI and there orig-tars (or zips) are the predominant distribution format. This may not be a showstopper since dgit does say it will work with tarball workflows, but I don't know how natural that is. Cheers, -Barry
Re: Best way to package a python module which is "private" with exposed calling script
On Tue, Feb 07, 2017 at 08:50:02AM -0500, Thomas Nyberg wrote: > I've been looking at the offlineimap package on my system (jessie), but in > my case `/usr/bin/offlineimap` is _not_ a symlink. Also the python code is > not installed to `/usr/share/offlineimap` and instead to > `/usr/share/pyshared/offlineimap/` and so if I start a normal interpreter > `import offlineimap` does work (which I'd rather it not). Am I completely > missing something here or did you possibly mean another example package? You should look at the sid package version, it's different there. -- WBR, wRAR signature.asc Description: PGP signature
Re: Best way to package a python module which is "private" with exposed calling script
On 02/07/2017 08:54 AM, Andrey Rahmatullin wrote: On Tue, Feb 07, 2017 at 08:50:02AM -0500, Thomas Nyberg wrote: You should look at the sid package version, it's different there. Thanks a lot! (Should have been an obvious first step...) And thanks a lot everyone else! Also I figure I might as well mention on this list that I went through and put together a bare-bones example for myself. There are always minor finicky things with this (at least for me) so I figure I might as well link it in this thread for any future internet travelers. Might save them a little hassle... https://github.com/ApproximateIdentity/debian-private-package
Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On Tue, Feb 07, 2017 at 10:47:00AM +, Ghislain Vaillant wrote: > I know the discussion is leaning towards replacing usage of git-dpm > with gbp-pq. I have nothing against it but, since we are talking about > solutions for a git-centric workflow, has anyone considered the dgit- > maint-merge workflow [1]? > > [1] https://www.mankier.com/7/dgit-maint-merge Quoting from that manpage: | Debian modifications to the upstream source are squashed into a single diff, | rather than a series of quilt patches. No, please let’s not use this. (I am with ScottK here.) The gbp-pq approach looks fine to me. -- Dmitry Shachnev signature.asc Description: PGP signature
