Breaking deps deliberately

[Toshio Kuratomi]

Richard W.M. Jones wrote:
> On Thu, May 14, 2009 at 01:37:48AM -0700, Toshio Kuratomi wrote:
>> Richard W.M. Jones wrote:
>>> On Wed, May 13, 2009 at 03:28:53PM -0700, Toshio Kuratomi wrote:
>>>> Do any other distributions purposefully add broken dependencies to their
>>>> repositories (So that you wouldn't be able to install it without
>>>> pointing at a second source for a package)?
>>> Debian allows them, 
>> Where is the documentation of this policy?  because...
>>
>>> and they have a special program called 'equivs'
>>> which you can use to locally compile packages in order to satisfy such
>>> broken dependencies:
>>>
>>> http://www.debian.org/doc/manuals/apt-howto/ch-helpers.en.html
>>>
>> This just explains how the equivs command works and how a user can use
>> it if they've installed a piece of software from outside the packaging
>> system and then want to list it as being available to the package manager.
> 
> This is getting a bit off-topic, but anyhow ...
> 
> The Debian Reference Manual suggests using equivs:
> 
> http://www.debian.org/doc/manuals/reference/ch-package.en.html#s-apt-trouble
> 
This one suffers the same problem as the equivs page you gave earlier.
It's talking about troubleshooting a system that has dep problems in the
installed system.  It's not defining the policy for the package
repository.  There's a variety of ways that a package can become a
broken dep over time without being one in the repository.  One example:

Fedora-1
Install foo that depends on libbar.so.1

Fedora-2
foo is no longer provided in the repository.
Only libbar.so.2

If you upgrade from Fedora-1 to Fedora-2 you have a broken dep on your
system for libbar.so.1.  This is not because of broken deps inside of
the repository.  It's because you have an old program installed from
before the time that libbar was upgraded to a new version.


> The Debian Policy Manual contains explicit rules about broken
> dependencies here:
> 
> http://www.debian.org/doc/debian-policy/ch-archive.html#s-sections
> 
> As you can see, in Debian's main repository they explicitly disallow
> broken deps for certain types of deps, but Debian has quite a complex
> dependency system, so this doesn't apply for things like "Suggests"
> and "Enhances".  BTW "Recommends" was added to the above list in
> Debian Lenny - previous releases of Debian allowed main packages to
> Recommend packages outside main.
> 
This one's better.  It actually contains policy about what should not go
into a repository.  The first thing that strikes me is that actual
broken dependencies are disallowed in the "main" repository.
"Suggests", "Enhances" are not useful here as they are things that
neither cause a program to fail or cause a packaging transaction to
fail.  So Debian is in agreement with us on this point.

The second thing that I see is that Debian has a contrib repository.
This repository allows packages which require things that aren't in the
repository in order to build or execute.  We don't have anything like
this repository and never have.  Perhaps if you didn't suffer through
the Fedora Founding Flamewars this is not obvious, though?

> Anyway, I think my point is not that we should care about what Debian
> does, but that we should make what is and isn't allowed explicit in
> the Fedora packaging guidelines.
> 
After skimming the Debian Policy Manual, I think pointing out a way that
we differ from Debian might help.  This is the Abstract of the Debian
Policy Manual:

"""
Abstract

This manual describes the policy requirements for the Debian GNU/Linux
distribution. This includes the structure and contents of the Debian
archive and several design issues of the operating system, as well as
technical requirements that each package must satisfy to be included in
the distribution.
"""

In Fedora the Packaging Guidelines and Packaging Committee are
responsible for defining the "technical requirements that each package
must satisfy".  But the rest of this, in particular the "structure and
contents of the" archive, is the responsibility of FESCo, releng, the
Board, and the policy pages that they create.  Defining whether a
package is allowed to depend on something that cannot be satisfied from
the repositories for that distribution is a decision about the contents
of the repositories.  That should be defined in a FESCo Policy page.
Others have pointed you at multiple places where the distro policy
states that unresolvable deps are not okay.  If you think those are
insufficient you probably want to come up with something for FESCo to
state that would clarify that.

OTOH, if you think that it's clear that unresolvable dependencies are
not allowed in Fedora but are just unclear on how to tell if your code
is creating one, you can bring language to clarify that to the Packaging
Committee to add to the Packaging Guidelines.

-Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090514/e30eebd5/attachment.sig>