Bug#296175: package depends on itself

[Nicolas Boullis]

Hi,

On Mon, Feb 21, 2005 at 12:07:37PM +0100, Lo=EFc Minier wrote:
>         Hi,
>=20
> On dim, f=E9v 20, 2005, Nicolas Boullis wrote:
> >=20
> > While trying to update a woody system to sarge, I doscovered that the
> > libgtk2.0-0 depends on itself, which breaks upgrade of the package.
> > Please fix this broken dependency and consider fixing it for sarge
> > through testing-proposed-updates.
>=20
>  What problem did you get?  Could you paste the log of the error?  A lot
>  of people upgraded without experiencing any trouble.

I had the problem when trying to upgrade a computer with aptitude's UI=20
=66rom woody to sarge. When I was trying to upgrade libgtk2.0-0, aptitude=
=20
was considering the new version broken, and was refusing to upgrade it.
(Oddly, it was considering it broken, but wasn't showing any missing=20
dependency.)

I had to upgrade this system so I manually "dpkg -i --force-depends"ed=20
libgtk2.0-0 and then coulf finish the whole upgrade.

Unfortunately, I now can't reproduce the problem in a clean woody=20
chroot, which means the problem probably is slightly more complex than I=20
initially thought.


> > (This bug may be a policy violation, deserving a serious bug report, bu=
t=20
> > I did not check.)
>=20
>  I agree this self-dependency is weird and a bit bogus, but it isn't
>  explicitely forbidden by the policy and didn't cause breakage until
>  now.  We'll try to fix it, but I don't think that deserves a severity
>  higher than minor (if it causes no breakage).

Reading policy 7.2:
"
Depends
    This declares an absolute dependency. A package will not be=20
configured unless all of the packages listed in its Depends field have=20
been correctly configured.
"

OK, self-dependencies are not forbidden but, according to policy, all=20
the packages depended on must be configured before the depending package=20
can be configured. Hence, self-depending packages must be configured=20
before they can be configured, which mans they can't be configured.=20
Hence, as far as I understand it, policy considers such packages=20
uninstallable.

(I've seen in a bug report that you temporarily merged with this one=20
that you consider that circular dependencies are alright. Reading the=20
same section of policy, I think the are not.)


Cheers,

Nicolas