Didier 'OdyX' Raboud schrieb:

Le vendredi 16 avril 2010 09:22:57 Frank Lin PIAT, vous avez écrit :

Splitting the file in /etc/usb_modeswitch.d/ increase the _disk_ pace usage
by 10 folds (400K instead of 28K).


This is an issue of the file system. It might be different for other setups.

IMHO, /etc/foo.d/ directory for configuration file is useful when other
packages ship files in the $foo.d/ directory. Or when a packages
receives a lot of updates (through volatile...), so the user isn't
asked to merge configuration file.


That's exactly why I did the split; the single config file was edited by users who often messed up. And I want human readability as much as possible.

> So a reasonable solution IMHO (and again, probably to be done upstream) would be
to modify both usb-modeswitch and u-m-data for the following (to be done separately probably):

* use configuration from two different places: /usr/share/usb-modeswitch-data would contain the "upstream stable configuration files" (or even all) and /etc/usb_modeswitch.d/ would contain the "still to be modified" (_:_:? e.g.) and the user provided ones. The /etc/* would take precedence over the /usr/* ones.

* enhance usb-modeswitch to be able to understand multiple configurations per file. This would allow to ship one upstream blob in /usr/share and keep working with separate files overrides in /etc/*

Josh: What do you think of all this ? I am somehow puzzled to propose yet-a-new paradigm change, but the path to technical perfection is sometimes zigzag. :-)


To be honest, I think there are more pressing issues at the moment, like getting NetworkManager to work flawlessly with every new modem.

There is no gain in space if the files are stored elsewhere.

If there is a project where space is so limited that these kB *do* matter, I'm willing to add a mechanism which can work with a tarball of the config files.

Otherwise, I trust that better file systems will change the picture soon.


Regards,
Josh




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to