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

Bug#863216: ITP: emacs-ivy -- a generic completion frontend for Emacs



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.

> 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.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature


Reply to: