On Thu, 2010-02-18 at 12:18 +0100, [email protected] wrote: > >> > >> I'd rather keep them optional, that's why the log tells if it misses blkid. > > > > Actually it doesn't. And it's only automatically selected if the base > > block-mount package is selected, so it is optional, but you don't have > > to worry about individual dependencies, and things work as expected > > without special effort out of the box. > > it does, for a good reason, functions/block.sh issues a log message if
Heh, I had forgotten I had done that. > blkid is missing, but uuid is used. I don't see how to separate a base > block-mount package, because the majority is replacing old mounting > routines. The thing to remember is the the /etc/init.d/fstab and 10-mount are for mounting optional filesystems. Neither of them is needed if you don't have storage beyond your rootfs (that is the boot rootfs (afaik squashfs, jffs2 or ext2), or squashfs (which is a boot rootfs) + jffs2 > I'd expect the new functionality to split in something like > > base-mount (which would be of package base-files because it replaces the > old fstab mounting and is therefore essential, consisting of the files But it's not essential. It's not used by preinit, which is where essential mounting is doing. /etc/fstab is kept around primarily in case some application expects to find something there and /etc/config/fstab is only used for optional filesystems. > you put in buildroot/package/base-files except of the hotplugd stuff) > menuconfig->Base system->hotplugd-block-automount (automount files, to > enable automount feature) > menuconfig->Base system->hotplugd-block-fsck (to enable fsck on hotplug > events) > > I'd suggest to put all hotplugd functionality in > buildroot/package/hotplugd-block. The hotplugd-block Makefile would > contain the package definitions mentioned above. The reason I divided the packages the way I did is so the the scripts weren't installed unless package that provided the capability to provide the function was present. e.g. btrfs fsck script only included when btrfs-progs is. Initially the core of the block-mount was to be included in base-files (which is what what you're talking about switching to again, but I might as well have left things the way I had them if we're going to to do that, because there is 5-8k of scripts that are hotplug only, and that's it), and the other script functions were to be added along with the package that provided the program need to use it. You didn't like that because it was too big. The thing unless you subdivide to fairly small chunk you can't have a proper matching of scripts to available functionality. I am personally opposed to installed the scripts willy-nilly and spamming the syslog with error messages if the dependencies aren't met. I think that is bad design. It's much better to include the script only if it won't cause the user to get error messages. Now if the user uses a config file with unsupported functions that's a different story...that's a configuration error. > >>> 2) It should be possible to pull in the dependencies for say > >>> block-blkid, from the base system menu (device-dependent submenu), > >>> rather than having to hunt down, say, blkid > >>> > >> > >> Sorry, not sure what you mean. Could you explain by example? > > > > Base System|Device Dependent > > > > should have packages such > > block-meta-blkid, that has the dependencies that pull in blkid and > > block-blkid (the package with the blkid mount stuff). > > Why is this submenu 'Device Dependent' needed? What does it tell the user? Device Dependent is for things like block-* that depend on having 'external' (non-boot rootfs) devices , or on certain wifi devices (like the toggle you mentioned before). It's more general than hotplug-scripts because it includes things other than just hotplug scripts. > > I see two solutions to this: > If we want to keep it simple and small it might make sense to simply > activate busybox's blkid per default. Have to doublecheck the size > increase though. > More elaborate could be, a basefiles subpackage setting > > menuconfig->Base system->basefiles > [ ] support mount by uuid or label > > . But maybe this is too much. I'd make it depending on the size increase > above. > > >> > >> me neither ;) .. but seriously. Circular dependencies only mean that > >> somebody did not look deep enough into setting them properly. > > > > Not true, with the limited dependency language we have. > > > > Show me an example that is not solvable. 1) Package C should be installed if both package A and be are B are installed (because of user expectations; A implies that it will use the functionality of B, if present, but that requires C) 2) Package C depends on A and B > >> packages that supply block devices: usb-storage, sdcard, ... > >> autoselect > >> packages that are needed to use these: e.g. block-mount > >> > > block-mount is *required* to use usb, it's just nice to have. That's > > why profile selection not autoselect. > > > > What do you mean? > > block-mount is *required* to use usb, > or > > it's just nice to have > ? sorry I meant not *required*, it's just nice to have. > > In my understanding I distinguish between basefile-block-(mount,fsck( > and the hotplugd-block-(automount,fsck). The basefile functionality is > there anyway, the hotplugd is optional. Actually users do not need There's no point to that. Hotplug only code accounts for <9k of scripts, total. In that case we should just got with my previous patch and forget about the separate packages. > automounting to use usb storage devices. They can use the terminal to > mount and stuff. But as hotplugd-automounting wasn't optional before on > second thought I'd vote for activating it by default, but make it not > depending on anything or anything depending on it. I think I'll wait to you've digested the correction on what's essential and what's not and the total size of the hotplug code. I also would like you to really think about the issue of badgering the user because they didn't fill a dependency (that is have scripts that are trying to execute functions but can't because the programs to do it aren't there). I think it's fundamentally flawed. Warning the user if they've configured things badly is different than failing to fill a dependency automatically when the promised functionality depends it. The following is a quote from the OpenWRT official documentation: Amount of flash memory Linux can hardly fit in a 2MB flash device, once you have opened the device and located the flash chip, try to find its characteristics on the Internet. If your flash chip is a 2MB or less device, your device is most likely to run a proprietary OS such as WindRiver VxWorks, or a custom manufacturer OS like Zyxel ZynOS. OpenWrt does not currently run on devices which have 2MB or less of flash memory. This limitation will probably not be worked around since those devices are most of the time micro-routers, or Wireless Access Points, which are not the main OpenWrt target. -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com
signature.asc
Description: This is a digitally signed message part
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
