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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
