How much added complexity in packages to cater for apt's shortcomings?

Saturday, January 23. 2010

Posted by Marc 'Zugschlus' Haber in Debian at 12:08 | Comments (18) | Trackbacks (0)

How much added complexity in packages to cater for apt's shortcomings?

It is well known that apt has an issue when it comes to resolving circular dependencies. Therefore, Debian bug reporters have set out to eradicate circular dependencies from the archive. This does, however, add significant bloat to the actual packages, and I am questioning why this is really necessary.

For example, aide. aide has an aide-common package, depending on aide | aide-binary. aide-binary is a virtual package by aide, aide-dynamic, and aide-xen. All three providers of aide-binary depend on aide-common again, which is a circular dependency.

If I now follow the request posed in #545852 and remove aide-common’s dependency on aide | aide-binary, I’ll have to cater for the case of the aide-binary bein absent in each and every helper script included in aide-common, which would drive the script’s complexity up to a new level. I really hate that idea.

Is it really necessary to work around apt’s shortcomings by eliminating the case that apt doesn’t handle well from the archive, and driving up other packages’ complexity (and the possibility of bugs in this added complexity)?

Defined tags for this entry: debian, debian-english, english

Related entries by tags:

Random Entry: Draußen nur Kännchen
< Block devices in KVM guests | OpenVPN with IPv6 in multi-client server mode >

Mark as read

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Isn’t a dpkg shortcoming involved, too? For dpkg, a dependency is a statement about order of configuration: if aide-common depends on aide, then aide must be configured before aide-common can be configured. And vice versa.

So one of the two dependencies really must not hold. Probably the truth is: aide must be unpacked before aide-common is configured, and aide-common must be configured before aide can be configured. (Here “configured” means “ready to satisfy other packages’ dependencies”.) Unfortunately, dpkg does not provide a way to say that, and if you are unlucky then the result might subtly break other packages that depend on aide.

Comments (9)

#1 Jonathan Nieder on 2010-01-23 13:20 (Reply)

> Isn’t a dpkg shortcoming involved, too?

Probably.

> So one of the two dependencies really must not
> hold. Probably the truth is: aide must be unpacked
> before aide-common is configured, and
> aide-common must be configured before ...

With aide, the situation is a little easier since the binary packages do not have any maintainer scripts. So the only dependency is that the aide binary package needs to be present and unpacked before aide-common is configured. Things have been like this for years in aide and I haven’t heard of any trouble.

Comments (7)

#1.1 Marc 'Zugschlus' Haber (Homepage) on 2010-01-23 20:21 (Reply)

> With aide, the situation is a little easier since the
> binary packages do not have any maintainer scripts.

In that case, as Joey implied, the circular dependency should be fine. I agree with you that obfuscating aide-common to avoid one is not a good idea.

Thanks for the interesting example.

Comments (9)

#1.1.1 Jonathan Nieder on 2010-01-25 01:34 (Reply)

Just to be explicit (to help people of the future who may read this):

The dpkg problem is documented in policy §7.2: [1]

| In case of circular dependencies, since installation or
| removal order honoring the dependency order can’t
| be established, dependency loops are broken at some
| point (based on rules below), and some packages may
| not be able to rely on their dependencies being present
| when being installed or removed, depending on which
| side of the break of the circular dependency loop they
| happen to be on.

So in general, a circular dependency can be dangerous...

| If one of the packages in the loop has no postinst
| script, then the cycle will be broken at that package,
| so as to ensure that all postinst scripts run with the
| dependencies properly configured if this is possible.
| Otherwise the breaking point is arbitrary.

... but in this case, it is not.

The only reasons left to care are complication and that reference-counting tools looking for leaf packages to delete can have a hard time finding the cycle.

[1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

Comments (9)

#1.1.1.1 Jonathan Nieder on 2010-01-26 19:27 (Reply)

In parent comment, I said this circular dependency is safe.

But my reasoning is wrong.

The unspoken assumption: if a package outside a dependency loop depends on a package in a dependency loop, it will wait for all packages in the loop to be configured before running its postinst. Looking at the source, I’m pretty sure that assumption is just wrong. Agh!

So there’s an idea for improving dpkg without adding any dependency fields.

Sorry for the nonsense.

Comments (9)

#1.1.1.1.1 Jonathan Nieder on 2010-01-26 19:49 (Reply)

On second thought: maybe the aide binary could be moved to a new aide-bin package and aide become an empty package with Depends: aide-bin, aide-common.

Ugly, but I think it would work.

As for the question you asked --- um, probably no? ;-)

Comments (9)

#2 Jonathan Nieder on 2010-01-23 13:30 (Reply)

> On second thought: maybe the aide binary could be
> moved to a new aide-bin package and aide become
> an empty package with Depends: aide-bin,
> aide-common.

There are three packages providing an aide binary. The default package (the one without the suffix) has a statically linked binary as recommended by upstream, aide-dynamic has a dynamically linked binary as requests by some users (at the expense of a significant security risk), and aide-xen is IIRC patched to be a better neighbor on xen guests.

I don’t see whether your suggestion is going to help with the situation.

Comments (7)

#2.1 Marc 'Zugschlus' Haber (Homepage) on 2010-01-23 20:19 (Reply)

I was imagining something like this:

aide - Depends: aide-common, aide-static | aide-binary
aide-static - Recommends: aide, Provides: aide-binary
aide-dynamic - Recommends: aide, Provides: aide-binary
aide-xen - Recommends: aide, Provides: aide-binary
aide-common - Depends: aide-static | aide-binary

But really, the churn alone would not be worth it. I was imagining a situation worse than it is.

Comments (9)

#2.1.1 Jonathan Nieder on 2010-01-25 01:40 (Reply)

> aide - Depends: aide-common, aide-static | aide-binary
> aide-static - Recommends: aide, Provides: aide-binary
> aide-dynamic - Recommends: aide, Provides: aide-binary
> aide-xen - Recommends: aide, Provides: aide-binary
> aide-common - Depends: aide-static | aide-binary

Wouldn’t work. Imagine somebody installing aide-dynamic without recommends, who would end up without aide-common.

Comments (7)

#2.1.1.1 Marc 'Zugschlus' Haber (Homepage) on 2010-01-25 09:37 (Reply)

Yes, it would silently break on upgrade. Forget I said anything. *sigh*

(Here is the ugly workaround for that:

aide - Depends: aide-common, aide-static-bin | aide-binary
aide-static-bin - Recommends: aide, Provides: aide-binary
aide-dynamic-bin - Recommends: aide, Provides: aide-binary
aide-xen-bin - Recommends: aide, Provides: aide-binary
aide-common - Depends: aide-static-bin | aide-binary

aide-dynamic - (transitional package) Depends: aide, aide-dynamic-bin
aide-xen - Depends: aide, aide-xen-bin

Surely this is not worth it.)

Comments (9)

#2.1.1.1.1 Jonathan Nieder on 2010-01-25 11:40 (Reply)

> aide - Depends: aide-common, aide-static-bin | aide-binary
> aide-static-bin - Recommends: aide, Provides: aide-binary
> aide-dynamic-bin - Recommends: aide, Provides: aide-binary
> aide-xen-bin - Recommends: aide, Provides: aide-binary
> aide-common - Depends: aide-static-bin | aide-binary
> aide-dynamic - (transitional package) Depends: aide, aide-dynamic-bin
> aide-xen - Depends: aide, aide-xen-bin

That would still leave people installing aide-dynamic-bin without recommends without an aide-common.

Comments (7)

#2.1.1.1.1.1 Marc 'Zugschlus' Haber (Homepage) on 2010-01-25 12:30 (Reply)

> That would still leave people installing aide-dynamic-bin
> without recommends without an aide-common.

Yes, that is by design. Similarly, vim-common does not depend on vim, libgtk2.0-common does not depend on libgtk2.0-0, and openssh-blacklist does not depend on openssh. The main downside is that people with aide-dynamic-bin but not aide-common installed might be tempted to run aide and find it broken; to fix this, one could install the binary to /usr/lib/aide and install a symlink in /usr/bin in the aide-common postinst.

Comments (9)

#2.1.1.1.1.1.1 Jonathan Nieder on 2010-01-26 09:29 (Reply)

> and install a symlink in /usr/bin in the aide-common
> postinst

Or, better, the aide postinst.

Do you actually want to do this? (If so, I’d be glad to look at the package and try modifying it accordingly. I’m still unconvinced it is a good idea.)

Comments (9)

#2.1.1.1.1.1.1.1 Jonathan Nieder on 2010-01-26 09:35 (Reply)

This is already done with a wrapper in aide-common.

Comments (7)

#2.1.1.1.1.1.1.1.1 Marc 'Zugschlus' Haber (Homepage) on 2010-01-26 12:48 (Reply)

Aide is a security tool. I hate the idea of having people with an inoperable aide because of a dpkg shortcoming.

Comments (7)

#2.1.1.1.1.1.1.2 Marc 'Zugschlus' Haber (Homepage) on 2010-01-26 12:47 (Reply)

And why exactly does aide-common depend on aide | aide-binary? Can’t the dependency been dropped or switched to a Recommends?

Comment (1)

#3 Corsac on 2010-01-23 13:48 (Reply)

>And why exactly does aide-common depend on aide | aide-binary?

Because the scripts coming with aide-common are much easier if they can rely on the fact that there is an aide binary available.

>Can’t the dependency been dropped or switched to a Recommends?

Only by adding additional complexity to aide-commons’s scripts which need to check whether there is an aide binary available and handle the “not available” case gracefully. This is exactly the situation I’d like to avoid.

Comments (7)

#3.1 Marc 'Zugschlus' Haber (Homepage) on 2010-01-23 20:17 (Reply)

It’s perfectly fine to have circular dependencies if you are aware that dpkg has to break the loop somewhere to configure the package, and you handle that properly.

IIRC, dpkg chooses to break dependency loops at packages that have no maintainer scripts. Thus, your aide-binary packages will be configured before aide-common is configured, and, presumably, nothing will break.

Bill has been filing scattershot circular dependency bugs for years. I assume he does this because he thinks that analising, dealing with, and avoiding breaking circular dependency handling is too complex for DDs to handle.

Perhaps the thing to do is to exhaustively document exactly how to use circular dependencies safely with dpkg. Then people can stop being afraid of them.

Comment (1)

#4 Joey Hess (Homepage) on 2010-01-23 20:04 (Reply)

Add Comment

Name
Email
Homepage
In reply to
Comment	HTML-Tags will be converted to Entities. Enclosing asterisks marks text as bold (word), underscore are made via _word_. Pavatar, Pavatar, Pavatar, Pavatar, Pavatar, Pavatar author images supported. To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly. Enter the string from the spam-prevention image above:
	Remember Information?

How much added complexity in packages to cater for apt's shortcomings?

Zugschlusbeobachtungen

Saturday, January 23. 2010

How much added complexity in packages to cater for apt's shortcomings?

IPv6 Check

Quicksearch

Blog Administration

Categories

Recently added

Comments

Syndicate This Blog

Show tagged entries

Template dropdown

Technorati

Twitter Timeline

Static Pages