Home

Advertisement

May 2008

S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031

Tags

Powered by LiveJournal.com

Free Software and Linux should not be a choose-your-own-adventure game

Fairly recently, I ran out of disk space. If you're a developer, especially one who uses things like JHBuild, virtualization, etc. - this has almost certainly happened to you. The consequences are pretty unpleasant (search for disk space in the GNOME bugzilla).


This got me to wondering - why the heck didn't GNOME have a low disk space notification? This morning I decided to look into that. Certainly a patch would be not more than 100 lines to do a libnotify notification, along with an action to say empty your trash.


It turns out that I (and at least Fedora) had been victim of two things. 1) autoconf 2) GNOME release policy.


What happened of course is that the code exists - it was just conditional on libnotify-devel being installed. From the Fedora gnome-volume-manager build log:



checking for NOTIFY... no

So the the support wasn't being compiled in, for who knows how long. I just fixed this for Rawhide, but we need to stop thinking of Linux as a source of random bits that you can put together optionally, and instead think of it as one unified stack. That means if you're a software maintainer - your check should not be if (have_libnotify_h), but instead if (linux) { require(libnotify_h) }. GNOME release policy totally ignores the fact that the vast majority of people using GNOME have these components. I understand the desire for things to be optional - we want GNOME to work on Maemo and new devices where not all of the stack may exist. But the right approach is for these new distributions to use flags like --disable-notify. Or we can use a semi-standardized flag like --enable-maemo, since often these non-desktop devices require other source changes too.

Posted on Feb. 9th, 2008 at 12:55 pm | | Leave a comment | Add to Memories | Tell a Friend

Comments

(Anonymous)

still could use your patch

Since nautilus now handles automounting in rawhide, I guess gnome-volume-manager is going to be phased out eventually...

It might make sense to have a gnome-settings-daemon watchdog style plugin that watches for low diskspace and related things.
Posted on Feb. 9th, 2008 07:13 pm (UTC) | | Thread | Reply

(Anonymous)

Re: still could use your patch

Just means we'll have to move the check from G-V-M to Nautilus, doesn't invalidate his point that this shouldn't be a game, that these things should be more automatic and more obvious when things like this go wrong.

Users need to know when drives hit full (or when they're quickly on the road to being full). Not doing this is a pretty huge mistake (IMO). It's about time we move libnotify and notification-daemon as a part of the platform so that this isn't a game anymore.

(Really, come on; it's a couple hundred kilobytes of well debugged code, and the only real objection to it is the libsexy requirement, which would be trivial to remove with an ifdef WITHOUT breaking significant functionality)
Posted on Feb. 9th, 2008 08:05 pm (UTC) | | Parent | Thread | Reply

[info]asabil.wordpress.com

I think the right approach to this is a build system that is able to handle dependency profiles (or variants). Maybe is it about time to drop autotools for something else ?
Posted on Feb. 9th, 2008 07:15 pm (UTC) | | Thread | Reply

[info]dbn3

Where to point the finger?

The information is all there. Isn't it the fedora maintainers responsibility to check for BuildRequires? "Checking for NOTIFY... no". "Hmm, maybe I should investigate that?" I would think that's pretty standard practice for the package maintainer.

I don't really see how you can pin the blame on autoconf. Whether you want libnotify to be a strict requirement has nothing to do with autoconf.
Posted on Feb. 9th, 2008 07:29 pm (UTC) | | Thread | Reply

[info]cgwalters

Re: Where to point the finger?

Actually I do partially blame autoconf - the philosophy behind it of testing for individual features is wrong. There are only 5 operating systems that matter. Three of these (Linux,Solaris,FreeBSD) share essentially the same set of interesting software. You can require the same software to be installed on all of them. The other two (OS X and Windows) are special, but that just gives you 3 total cases.
Posted on Feb. 9th, 2008 09:11 pm (UTC) | | Parent | Thread | Reply

[info]dbn3

Re: Where to point the finger?

But that's still not because of autoconf. That's the philosophy of whoever's maintaining the package. No matter what configuration tool is used, it's still in the control of the packager whether certain components are required or optional. And I agree, libnotify is a "standard" component in my eyes, but that's a separate issue than using autoconf.
Posted on Feb. 10th, 2008 06:05 am (UTC) | | Parent | Thread | Reply

[info]jmmv

Or ask software authors to drop automatic detection of dependencies. They are evil, pure evil. Sure, it simplifies building from source code, but if you are doing that already by hand, you should be ready to deal with some oddities (such as manually having to disable dependencies). For everyone else (packagers), they are a nightmare.

I already ranted about this in the following article, and provided some suggestions (and code!) on how to improve the situation non-intrusively:

http://www.onlamp.com/pub/a/onlamp/2005/03/31/packaging.html?page=2#automatic_decisions
Posted on Feb. 9th, 2008 07:43 pm (UTC) | | Thread | Reply

[info]rhpennin

yes/no/auto

One simple approach is to copy how dbus configure works; the config options can be yes, no, or auto.

- yes means error if dependency not found
- auto means use it only if it's found

The main idea here was that an RPM package can --enable-foo=yes to force the dependency to be found when building the RPM.

Doesn't help if the packager doesn't know about the dep, I guess.
Posted on Feb. 9th, 2008 11:02 pm (UTC) | | Thread | Reply

(Anonymous)

Re: yes/no/auto

In that case, defaults should only be "yes" or "no". Auto puts us right back where we are right now.
Posted on Feb. 9th, 2008 11:58 pm (UTC) | | Parent | Thread | Reply

[info]cgwalters

Re: yes/no/auto

And even with "yes/no", one should think carefully about defaulting to "no".
Posted on Feb. 10th, 2008 12:05 am (UTC) | | Parent | Thread | Reply

[info]kevin_kofler

Optional dependencies

This is not a GNOME-specific problem, KDE suffers from the exact same disease (I know the Gentoo guy complained about this at Akademy, but nothing changed), though at least KDE clearly lists what optional dependencies have been found and which haven't at the end of the configure or cmake run, not just in the "checking for ...: no" format.

This isn't an autoconf problem either. Not that I like the autotools (and in fact I'm glad KDE 4 is now using cmake instead), but in this case it's just mechanism. The real problem is how it is being used. KDE 4 implements the same policy using cmake, and it's possible to implement better policies with autoconf.

IMHO, all dependencies which are necessary to implement some feature should be treated as required by default. If the feature is truly important, it should be impossible to disable the dependency (without patching the source code, of course, this is Free Software after all). Otherwise, an explicit --disable-foofeature or --without-foolib should be required to build without it. Building with missing features should be a concious decision by the user/packager, not just due to some -devel package happening to be missing.
Posted on Feb. 10th, 2008 03:05 am (UTC) | | Thread | Reply

[info]fooishbar

You were veering in a direction that was at least vaguely sensible (we should be able to rely on a set of standardised base components), but suddenly you went off on an absurd, nonsensical tangent.

Why would you replace something that's objectively correct (use libnotify if it exists; warn/error if it doesn't) with something that isn't (based on the platform, assume you must have it)?

Put another way, if I wanted to know whether or not I could get a lift off someone, I'd be asking them if they owned a car, not asking them if they were American, and subsequently drawing the conclusion that they must own cars.

X is just emerging from the platform-test madness and moving towards feature tests, and I can tell you that the other side makes zero sense.
Posted on Feb. 10th, 2008 12:33 pm (UTC) | | Thread | Reply

[info]kevin_kofler

Because...

... what matters here is not what packages happen to be currently installed, but what packages are available! Somebody running GNU/Linux can install libnotify, so they should be required to do so unless they explicitly say they don't want the feature requiring it. (And actually I'd be inclined to suggest just requiring it for all platforms, the proper solution if the library is not available is porting the library, not crippling the applications requiring it.) If the package is silently (and I'd qualify everything less than a hard error as "silent" because almost nobody actually looks at configure logs, end users don't understand them and during packaging they're hidden on the build system and most packagers only check them if there was an error) built without some dependencies, you'll end up with software which is missing some of its features, this shouldn't be a default. For those users who really don't want the feature, it should be a concious decision to disable it, and that's what --disable-* or --without-* options are for.
Posted on Feb. 10th, 2008 04:28 pm (UTC) | | Parent | Thread | Reply

[info]fooishbar

Re: Because...

Right, so change the logic to this:
if ! "x$with_libnotify" = xno; then
    check_for_libnotify_or_error_out
else
    libnotify_explicitly_disabled
fi
not:
if "x$platform" = xlinux; then
    we_have_libnotify_the_compile_will_fail_if_not
else
    we_dont_have_libnotify
fi
The former makes sense. The latter does not; not here, and not in any parallel universe.
Posted on Feb. 10th, 2008 05:45 pm (UTC) | | Parent | Thread | Reply

(Anonymous)

This got me to wondering - why the heck...

This got me to wondering - why the heck the - "funcionalitty" of "network monitor" applet isn't merged into "network manager" applet (including alterning of icon colors during network activity)
Posted on Feb. 10th, 2008 01:25 pm (UTC) | | Thread | Reply

[info]http://openid.aol.com/jhaygood86

I totally agree!

Application writers should require by default all functionality. Packagers can disable select functionality, but by default the source package should require it so that people don't accidently disable things :)
Posted on Feb. 11th, 2008 07:28 pm (UTC) | | Thread | Reply

Advertisement