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

Re: Bug#818115: turn python-sphinx into an arch:any package



Hi Helmut,

On Thu, May 12, 2016 at 08:40:00PM +0200, Helmut Grohne wrote:
>> 161 is many packages, though in my opinion splitting the documentation into
>> arch:all packages is something that should be done independently of this bug.
>> Maybe we can have some kind of DD list whose packages are affected by this?
>> (Or a Lintian warning, see below.)
>
> Computing this list in an automated way is difficult, because
> build-rdeps has no way of ignoring Build-Depends-Indep (even though the
> underlying dose can do that, though not in unstable as Johannes just
> told me).

reverse-depends -b src:sphinx [1] returns multiple lists for B-D and B-D-I,
but a *huge* part of the B-D group is packages that don't have arch-dep
stuff at all (i.e. pure Python packages).

[1] where reverse-depends is from ubuntu-dev-tools

> This is not as clear cut. Sometimes documentation is small. We tend to
> not split out every single bit of documentation into arch:all packages.
> To the contrary, manual pages tend to be included with the main package.
> I do not see consensus for this increase in the number of binary
> packages.

Right, but we were talking about the solutions to cross issues...

> If the dh addon is not to be used, you should deprecate it. I actually
> find the addon useful, because it removes complexity (unless you do
> [1]). In an ideal world, we would maybe say "dh $@ --with-indep sphinx"?

I won't deprecate it because Sphinx was developed for Python and most
Python packages don't have any arch-specific stuff at all, so for them
--with sphinxdoc works fine.

A --with-indep option would be nice indeed :)

> > Alternatively, as you suggest, such packages may build-depend on sphinx-common
> > and I may mark sphinx-common as Muili-Arch: foreign. If it helps then I will
> > do that.
>
> It's the simplest workaround that I see. Of course, people need to
> remember to Build-Depend on sphinx-common to use the addon, which is
> complexity of its own. If we pursue that road, we should document it
> precisely (e.g. README.Debian?).

So should I go ahead and add M-A: foreign attribute to sphinx-common?

I can also document it in README.Debian but I am not sure I will find
proper wording to describe the problem. Maybe you can help me with that?
If you could do that, then I'll be able to describe the solution myself.

--
Dmitry Shachnev

Attachment: signature.asc
Description: PGP signature


Reply to: