Hi Sean, On Tue, May 30, 2017 at 07:53:51AM +0100, Sean Whitton wrote: > Dear Nicholas, > > On Mon, May 29, 2017 at 02:53:57PM -0400, Nicholas D Steeves wrote: > > E: emacs-ivy source: license-problem-gfdl-invariants doc/ivy.org > > E: emacs-ivy source: license-problem-gfdl-invariants doc/ivy.texi > > > > I'd like to generate a non-free emacs-ivy-doc package for these, so > > long as there isn't a pkg-emacsen policy that prevents this. > > There isn't. > > > IIRC, DFSG-free packages cannot recommend non-free ones, but can they > > suggest non-free ones? > > This sounds sensible but it's not in Policy. > > > Also, when I adopted src:muse-el I noticed that the previous author > > had stripped GFDL docs, and I forget if they're permitted in Alioth > > git repos. > > Don't worry. It's fine for them to be on alioth.
I've renamed emacs-ivy/master to emacs-ivy/master-nonfree, and pushed
and renamed new master and upstream branches that automatically strip
out the non-DFSG stuff when uscan is run--using upstream tarball,
because that's what I'm familiar with rather than a git-based
Files-Excluded work-flow. HEAD still points to master-nonfree. Do you
think the following is the best course of action?:
Rename master-nonfree to something that better signifies it's only
used for merging (from upstream git remote) upstream docs; document
this somehow (README.sources? In both branches, or just in one of
them?); maybe drop upstream-nonfree, strip out all non-docs from
newname-for-master-nonfree, and build the non-free emacs-ivy-docs
orig.source using deborig? This orig.source seems like it only needs
to contain the emacs-ivy/docs subdir. Finally, debian/* on the
newname-for-master-nonfree branch would need to be modified.
At this point I don't think that the change in the git repo will
affect more than three people...and maybe git does something magical
and automatic that makes it a non-issue?
> > Other than this, I'm perplexed by the following, because I thought
> > that dependencies would recurse, eg: elpa-swiper depends on elpa-ivy,
> > which has ${elpa:Depends}, ${misc:Depends}, emacsen-common (>= 2.0.8):
> >
> > W: emacs-ivy source: debhelper-but-no-misc-depends elpa-swiper
> > W: emacs-ivy source: debhelper-but-no-misc-depends elpa-counsel
> > W: emacs-ivy source: debhelper-but-no-misc-depends elpa-ivy-hydra
>
> The dependencies do recurse but debhelper might need to add different
> entries to ${misc:Depends} for different binary packages -- it is not
> able to look down the dependency graph and insert those entries into the
> ${misc:Depends} of a different binary package. So you need to add it to
> all of them.
Thanks! :-) Fixed.
On 30 May 2017 at 03:12, Sean Whitton <spwhit...@spwhitton.name>
wrote:
> On Tue, May 30, 2017 at 07:53:51AM +0100, Sean Whitton wrote:
>> On Mon, May 29, 2017 at 02:53:57PM -0400, Nicholas D Steeves wrote:
>> > IIRC, DFSG-free packages cannot recommend non-free ones, but can they
>> > suggest non-free ones?
>>
>> This sounds sensible but it's not in Policy.
>
> ... but it is in the upcoming Policy 4.0.0 that packages should
> Suggest
> their -doc packages.
Oh wow. I wonder if this will reignite the GFDL debate... In the
case of emacs-ivy-doc the main issues are something to the affect of
"This is a GNU manual" front cover and "This document can be freely
distributed and modified" back cover...but after having learned that
GNU licenses are only valid in English, the back cover doesn't seem
like an issue to me. That said, it is mildly troubling that the front
cover must always be in English (and only in English) and cannot be
modified to be more informative...
Cheers,
Nicholas
signature.asc
Description: Digital signature
