>> > 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. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
