Bug#892562: qutebrowser has circular Depends on qutebrowser-qtwebengine|qutebrowser-qtwebkit

2018-03-17 Thread Axel Beckert 
Control: tag -1 + wontfix

Hi Bill,

Bill Allombert wrote:
> Rename  qutebrowser -> qutebrowser-common
> qutebrowser-qtwebengine -> qutebrowser + Provides qutebrowser-qtwebengine
> Change qutebrowser and qutebrowser-qtwebkit to Depend on qutebrowser-common.
> Change qutebrowser-common to not depend on
> qutebrowser-qtwebengine|qutebrowser-qtwebkit

You don't seem to have understood how these packages work:

/usr/bin/qutebrowser is in the package qutebrowser. And that's the
primary package a user will select for installation in most cases. So
it does not make sense to rename that package.

The other two package are primarily dependency packages (depend on
multiple packages needed for the according rendering engine) and only
secondarily metapackages for installation. i.e. if and only if the
user wants a specific rendering engine (or both), then the user
selects either qutebrowser-qtwebengine, qutebrowser-qtwebkit (or
both), otherwise qutebrowser pulls in at least one of these rendering
engines — depending on the architecture as not both rendering engines
are available on all architectures.

Hense your suggestion is moot, because then qutebrowser-common would
have an RC bug as it does not depend on "qutebrowser-qtwebengine |
qutebrowser-qtwebkit" which /usr/bin/qutebrowser requires to work as
it needs at least one of the two rendering engines.

I could drop the dependency on qutebrowser in qutebrowser-qtwebengine
and qutebrowser-qtwebkit. Then they would only serve as dependency
packages and no more as metapackages.

But I refuse to do that unless someone proves (or someone I trust in
that matter declares, e.g. the APT developers, Cc'ed) that these
source-package-internal dependency loop is really an issue for APT
_nowadays_. Tagging as "wontfix" until I have feedback from either the
APT developers or someone who can prove that these dependency loops
cause issues.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#892562: qutebrowser has circular Depends on qutebrowser-qtwebengine|qutebrowser-qtwebkit

2018-03-17 Thread Bill Allombert 
On Sat, Mar 10, 2018 at 11:13:53PM +0100, Axel Beckert wrote:
> Control: tag -1 + moreinfo
> 
> Hi Bill,
> 
> Bill Allombert wrote:
> > There is a circular dependency between qutebrowser and
> > qutebrowser-qtwebengine|qutebrowser-qtwebkit:
> 
> Yes, I'm aware of that.
> 
> Otherwise we would need two additional binary packages (with nearly
> the same names as the existing ones) where one set would be meta
> packages, pulling in the relevant dependencies and the other set would
> be meta packages pulling in qutebrowser and the according dependency
> package, e.g.

Do you really need two additional binary packages ?

For example:
Rename  qutebrowser -> qutebrowser-common
qutebrowser-qtwebengine -> qutebrowser + Provides qutebrowser-qtwebengine
Change qutebrowser and qutebrowser-qtwebkit to Depend on qutebrowser-common.
Change qutebrowser-common to not depend on
qutebrowser-qtwebengine|qutebrowser-qtwebkit

> (*) Will be difficult to cause problems with buster to stretch updates
> since qutebrowser is not in stretch, so there can't be any upgrade
> issues from stretch to buster.

Of course not, it cause problem during buster to buster+1, at a point 
where fixing buster is not an option anymore.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Bug#892562: qutebrowser has circular Depends on qutebrowser-qtwebengine|qutebrowser-qtwebkit

2018-03-10 Thread Axel Beckert 
Control: tag -1 + moreinfo

Hi Bill,

Bill Allombert wrote:
> There is a circular dependency between qutebrowser and
> qutebrowser-qtwebengine|qutebrowser-qtwebkit:

Yes, I'm aware of that.

Otherwise we would need two additional binary packages (with nearly
the same names as the existing ones) where one set would be meta
packages, pulling in the relevant dependencies and the other set would
be meta packages pulling in qutebrowser and the according dependency
package, e.g.

qutebrowser-qtwebengine → qutebrowser, qutebrowser-qtwebengine-dependencies
qutebrowser-qtwebkit→ qutebrowser, qutebrowser-qtwebkit-dependencies
qutebrowser → qutebrowser-qtwebengine-dependencies | 
qutebrowser-qtwebkit-dependencies

Additionally, qutebrowser-qtwebkit-dependencies and
qutebrowser-qtwebengine-dependencies would at least need a "Suggests:
qutebrowser" if not a "Recommends: qutebrowser" as they're not useful
at all without an installed qutebrowser package (but cause no harm
without it).

> Circular dependencies are known to cause problems during upgrade
> between stable releases, so we should try to avoid them.

And FTP masters say we should try to avoid additional binary packages
unless necessary. (The two new ones are necessary because otherwise
dependencies of the type "(a & b) | (c & d)" cannot be expressed,
i.e. previously the dependencies in the qutebrowser package were
either too weak or too strong.)

> See threads 
> http://lists.debian.org/debian-devel/2005/06/msg02111.html
> http://lists.debian.org/debian-devel/2005/11/msg01101.html

I'm sorry, but I doubt that a discussion from more than a decade ago
reflects today's dependency resolver implementations and capabilities
of apt and aptitude. Cc'ing the apt developers for their input on
this. (No need to Cc the aptitude developers. I am one of them and I
can't remember circular dependencies being an issue for aptitude's
dependency resolver.)

So if either the apt developers consider such circular dependencies
still a severe enough issue today, or if anyone provides a current
real world example(*) where this circular dependency causes a
dependency resolver problem in either apt or aptitude (and given that
the FTP Masters will accept two additional empty meta packages as
outlined above), I will consider this request. Otherwise it will be a
"wontfix" for me.

At least so far piuparts found no such issues when these dependencies had
been introduced:
https://piuparts.debian.org/testing2sid/source/q/qutebrowser.html

Nor did
https://qa.debian.org/debcheck.php?dist=unstable=qutebrowser
report any problem besides qtwebengine not being available on all
architectures.

(*) Will be difficult to cause problems with buster to stretch updates
since qutebrowser is not in stretch, so there can't be any upgrade
issues from stretch to buster.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#892562: qutebrowser has circular Depends on qutebrowser-qtwebengine|qutebrowser-qtwebkit

2018-03-10 Thread Bill Allombert 
Package: qutebrowser
Version: 1.1.2-1
Severity: important

Hello Fritz,

There is a circular dependency between qutebrowser and
qutebrowser-qtwebengine|qutebrowser-qtwebkit:

qutebrowser :Depends: qutebrowser-qtwebengine | qutebrowser-qtwebkit
qutebrowser-qtwebengine :Depends: qutebrowser (= 1.1.2-1)
qutebrowser-qtwebkit:Depends: qutebrowser (= 1.1.2-1)

Circular dependencies are known to cause problems during upgrade between
stable releases, so we should try to avoid them.

See threads 
http://lists.debian.org/debian-devel/2005/06/msg02111.html
http://lists.debian.org/debian-devel/2005/11/msg01101.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here.