[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: