Re: RFC: splitting deploy/ipk into subarchs

[Matthias Hentges <oe@hentges.net>]

Am Freitag, den 23.02.2007, 09:05 +0100 schrieb Koen Kooi:

> Matthias Hentges schreef:
> > Am Dienstag, den 20.02.2007, 14:48 +0100 schrieb Koen Kooi:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Koen Kooi schreef:
> >> 
> > Why not make this change optional via a variable 
> > (ie: SPLIT_DEPLOYDIR_IPK = -1 to turn it off) ?
> > 
> > The current version breaks local OE feeds
> 
> People's feeds are outside the scope of OE. Repeat after me: deploy never was, isn't and
> never will be a feed.

It worked just fine as a feed before the change and people were using
it as such, deal with it.

> > and requires needless post-processing.
> 
> As I pointed out before, you needed postprocessing anyway due to bugs in ipkg and
> ipkg-utils, so your point is moot.

You may have needed post-processing, I personally never did. Not even
when I was building for 4 machines.... As I said, the old deploy
directory worked just fine as a feed out of the box. If people weren't
using it as a feed, please explain the existence of
meta/package-index.bb.

> 
> > A slugos deploy dir looks like this now:
> > 
> > all
> > armv5te
> > i686
> > ixp4xxle
> > 
> > I honestly don't see any advantage to the previous mode of operation.
> 
> Go read the openembedded-devel list some time.

Well, If I wouldn't read it from time to time, I wouldn't have
responded to this thread in the first place.
Sounds logical, now, doesn't it?

> 
> > If
> > it is needed for unique situations 
> 
> No

Oh yes.

> > like the rare case of a multi-machine build
> 
> Apart from that now being the point, 

Yes, that's exactly the point. A change benefiting very few people
affecting basically every one in a mostly negative way.

> it actually isn't rare, the majority of the
> (maintained) distros in OE use it (celinux. generic, angstrom, openmoko, openzaurus,
> slugos and jline).

Oh right, because the majority of OE users are distribution maintainers,
right!
And every maintainer always builds every machine in existance. Sorry, I
forgot!
</sarcasm>

Your SlugOS exsample is pretty braindead as I had already shown you in
my previous email that slugos builds _suffer_ from the change, they
don't benefit from it. You do actually _read_ the emails you are
"responding" to, right?

SlugOS doesn't even use multi-machine magic to build images for
multiple supported machines (it may or may not use it for LE/BE
builds). You might wanna check with reality from time to time before
spouting nonsense.

> > it should be off by default and - by all means - optional.
> 
> No it should not. Next time respond to the RFCs instead of starting some uninformed rant
> afterward.

a) Not even 24 hours passed between the first email and the resulting
commit. What kind of RFC is that? How are people supposed to actually
comment on it (you know, the C part of RFC? ) if the commit is out
before most subscribers even noticed what was going on?

b) I do have other things on my mind than to read this mailinglist on
a daily basis. I only do so from time to time and respond to matters
of my concern and / or interest.

c) It wasn't a "rant", I was stating facts, even if you are too
close-minded to see it.

d) It was in no way uninformed. You may remember me maintaining my own
bloody distribution for multiple machines in the past? How much more
informed about this matter do you want me to get? I even gave a very
informed short example ( in the form of SlugOS ) of why I think the
change should be optional. If anyone is posting uninformed "rants", it
is you.

e) If you do not want any comments, then by all means, don't request
them! But if you actually _do_ care what other people think about a
certain matter, please stop responding like a know-all-be-all impolite
smart-ass that puts down other people for not thinking 100% alike.