Re: [oe-commits] org.oe.dev rootfs_ipk: as per OE, policy: remove feed management tools

[Rod Whitby <rod@whitby.id.au>]

Stelios Koroneos wrote:
> I am not sure how many of you are building multimachine distro's but the old
> system was not a very good solution.
> We are building a distro for a number of machines x86 arch (i486, i585,
> i686), a number of powerpc targets  and recently mipsel and puttinng
> everything in a giant ipk pool is not the best of solutions.
> 
> As far as i can understand its a case where  single machine distro's made
> use of this OE feature while multimachine distros had to look for other ways
> (i.e post processing).

Perhaps when multimachine was added, the deploy ipk feed support should
have been updated to continue to work, instead of later breaking single
machine feed support.

Just because it works for some, doesn't mean it works for all.  Just
because it doesn't work for some, doesn't mean it's not useful for others.

> From what i read so far there seems to be 2 solutions
> Either allow for the old behaviur of OE through some 'switch' and let the
> distro mainter decide what do to or document the new way of handling feeds.
> In my case i would prefer the second option, as both single and multimachine
> distro's could use the same mechanism to update their feeds

The third (and my preferred) option is not just to document the new way
of handling feeds, but fix OE to handle feeds in the multimachine case.
 OE is meant to make things easier and more consistent, not meant to
force people to *all* do postprocessing to do a common action (like
having a development feed or a simply rsync'ed public feed).

If a feature is commonly used, and fervently wanted by those who use it,
then breaking or deleting it is not a way to keep developers using OE
... especially in corporate situations like Andy recounted, where ease
of development feeds is a selling feature internally against other
home-grown build solutions.

-- Rod