Re: [PATCH] part type interface

[Neal H Walfield]

>> > I was thinking this code might be triggered by a user who requested a
>> > store_part on the command line to, say, ext2fs.  Is that incorrect?
>> 
>> If the hurd is compiled without libparted, then the "part" store type will
>> be completely absent, and using it on the command line will get the usual
>> error you'd get for using some unknown type "frobozz".
>
> Ok, I see where I was confused then.  I think I agree with Roland.  If
> the stub must be added, it should be ENOSYS, but even better is to
> just have it not added.  
>
> A program which wants store_part_create should have a dependency on
> libparted.  If libparted lives in the hurd packages, it should be
> always on.  If it's in a different package, then the package
> dependency mechanism should be used--just like any other library.

I think that you are still a bit confused.  The Hurd can be compile
with or without libparted support.  Libparted is a library from GNU
Parted, GNU's partition editor.

We have two scenarios: the Hurd with the parted support or without.
The case we are looking at now is without parted support and how to
fail gracefully.

Specifically, I am interested in how an application that uses
store_part_create will fail.  If the store_part_create function is not
available, the application will not be able to start.  Roland, I
think, is making the assumption, that all applications which depend on
this function will be compiled by the user.  However, even in this
case, a user could upgrade his Hurd and not recompile the
aforementioned package.  Thus, the package will not be able to take
advantage of the new functionality.

This is, of course, all moot.  No application will use
store_part_create directly.  Not to mention that we will eventually
turn parted support on by default.  That is, once a stable version is
available and in the Debian archive.