package usb-modeswitch-data tags 578024 +upstream thanks Le vendredi 16 avril 2010 09:22:57 Frank Lin PIAT, vous avez écrit : > Hello, > > Splitting the file in /etc/usb_modeswitch.d/ increase the _disk_ pace usage > by 10 folds (400K instead of 28K). > 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. > > Couldn't all the files in the .d directory be merged in a single file? > (that file could be /etc/usb_modeswitch.d/upstream) > > > Thanks, > > Franklin > > % du /etc/usb_modeswitch.d/ -h > 400K /etc/usb_modeswitch.d/ > > > % cat /etc/usb_modeswitch.d/* > /tmp/all > % du -h /tmp/al > 28K /tmp/a
Hi Franklin, and thanks again for your bugreport ! (Upstream CCed again) Historically, usb-modeswitch was shipped with one single file containing all the configurations and this file went splitted in multiple files to ease conffile transitions, additions and update. I still think that this model is very convenient for working out new devices, etc. Now I very much understand this space issue. Furthermore, providing so many configuration files somehow bloats the /etc space for things that are probably more of /usr scope. 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. :-) Frank: Does this sound sensible to you ? Cheers, OdyX -- Didier Raboud, proud Debian Maintainer (DM). CH-1020 Renens did...@raboud.com
signature.asc
Description: This is a digitally signed message part.
