On 28 June 2013 11:02, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> I appreciate the intention here but I'm not sure if this is really the> appropriate place to put this; packagegroup-core-boot is supposed to only> directly pull in the essentials required for booting. This will cause problems> for those people using alternative device managers (e.g. busybox mdev) as> well.>> I'm not sure where this should go, but adding it to VIRTUAL-> RUNTIME_dev_manager (in the distro config?) could work. Anyone else have any> better suggestion?
How about making udev RRECOMMEND udev-cache?
Ross

On Monday 01 July 2013 15:49:00 Burton, Ross wrote:
> On 28 June 2013 11:02, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:> > I appreciate the intention here but I'm not sure if this is really the> > appropriate place to put this; packagegroup-core-boot is supposed to only> > directly pull in the essentials required for booting. This will cause> > problems for those people using alternative device managers (e.g. busybox> > mdev) as well.> > > > I'm not sure where this should go, but adding it to VIRTUAL-> > RUNTIME_dev_manager (in the distro config?) could work. Anyone else have> > any better suggestion?> > How about making udev RRECOMMEND udev-cache?
It's not that udev-cache might not be available, rather that packagegroup-
core-boot shouldn't have any kind of reference to it. In any case unless udev
is skipped somehow, an RRECOMMENDS on udev-cache will end up building udev
even if you haven't selected it in VIRTUAL-RUNTIME_dev_manager so that won't
help.
Cheers,
Paul

On 1 July 2013 15:58, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> On Monday 01 July 2013 15:49:00 Burton, Ross wrote:>> On 28 June 2013 11:02, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:>> > I appreciate the intention here but I'm not sure if this is really the>> > appropriate place to put this; packagegroup-core-boot is supposed to only>> > directly pull in the essentials required for booting. This will cause>> > problems for those people using alternative device managers (e.g. busybox>> > mdev) as well.>> >>> > I'm not sure where this should go, but adding it to VIRTUAL->> > RUNTIME_dev_manager (in the distro config?) could work. Anyone else have>> > any better suggestion?>>>> How about making udev RRECOMMEND udev-cache?>> It's not that udev-cache might not be available, rather that packagegroup-> core-boot shouldn't have any kind of reference to it. In any case unless udev> is skipped somehow, an RRECOMMENDS on udev-cache will end up building udev> even if you haven't selected it in VIRTUAL-RUNTIME_dev_manager so that won't> help.
I mean add a recommends to the udev binary package itself, so you'll
get udev-cache if you build udev (and keep the existing udev-selection
logic as-is).
Ross

On Monday 01 July 2013 16:02:56 Burton, Ross wrote:
> On 1 July 2013 15:58, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:> > On Monday 01 July 2013 15:49:00 Burton, Ross wrote:> >> On 28 June 2013 11:02, Paul Eggleton <paul.eggleton@linux.intel.com>
wrote:
> >> > I appreciate the intention here but I'm not sure if this is really the> >> > appropriate place to put this; packagegroup-core-boot is supposed to> >> > only> >> > directly pull in the essentials required for booting. This will cause> >> > problems for those people using alternative device managers (e.g.> >> > busybox> >> > mdev) as well.> >> > > >> > I'm not sure where this should go, but adding it to VIRTUAL-> >> > RUNTIME_dev_manager (in the distro config?) could work. Anyone else> >> > have any better suggestion?> >> > >> How about making udev RRECOMMEND udev-cache?> > > > It's not that udev-cache might not be available, rather that packagegroup-> > core-boot shouldn't have any kind of reference to it. In any case unless> > udev is skipped somehow, an RRECOMMENDS on udev-cache will end up> > building udev even if you haven't selected it in> > VIRTUAL-RUNTIME_dev_manager so that won't help.> > I mean add a recommends to the udev binary package itself, so you'll> get udev-cache if you build udev (and keep the existing udev-selection> logic as-is).
Right, that could work yes.
Cheers,
Paul