On Wed, 2010-02-17 at 11:56 +0100, edgar.sol...@web.de wrote: > On 12.02.2010 22:13, Daniel Dickinson wrote: > > I think the packaging needs the following properties: > > 1) scripts for functionality (e.g. uuid and label, using blkid) are > > automatically installed if the main block-mount (as I've called) is > > installed, and the dependency is satisfied (.e.g if block-mount and > > blkid are both installed then block-blkid should automatically be > > selected for installation) > > > > 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. > > > 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). > > 4) Scripts for functionality should only be installed if the necessary > > dependencies are present (e.g. block-blkid shouldn't be installed > > without blkid and block-mount) > > This will be ensured by dependency definition in the Makefile. > > > NB: All conditions can't be met via a single package because menuconfig > > doesn't like circular dependencies > > > > 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. > > Also note that the attached patches are incomplete...I'm having > > difficulty getting menuconfig to do what I want, so I'm showing you what > > I've got, and letting you try. > > > > will do so. > > > because it it too small. I think that those wanting 2/8 devices to work > > should really think about working on a sister project that makes > > > > How did you perceive that openwrt is not targeting 2MB routers? a) developers have told me so b) ToH lists 2/8 devices as too small to be supported (and if there is any place it doesn't this is in error) 2/8 is very much tinkering with a system that just happens to be hackable to it, not a supported configuration. > > > To reiterate a 2/8 device should really be done with a different > > choice-base than OpenWRT because in that case you want less > > functionality and smaller size. > > > > Currently you have to menuconfig/compile your own image for these > devices. But I guess this is to keep the number of readymade images to > build countable. No, it's because 2/8 is officially not supported. The fact that OpenWRT can be hacked to work on these devices should not be taken to mean that it's an officially supported configuration. It's your problem if you can't get it work, or it breaks because of changes on officially supported devices. > >> usb-storage should simply be depending on it .. and then it will be there. > >> > > It's not only applicable to usb though. Anyway I think making > > block-mount a part of profiles for devices with usb or other block > > devices (other than the boot rootfs), would be appropriate. > > > Typically a package would be autoselected by different packages. e.g. > > 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. -- 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 openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
