[oe] [RFC] Setting default IMAGE_FSTYPES to tar.gz in bitbake.conf

[Paul Sokolovsky]

Hello,

On Sun, 10 Feb 2008 12:43:24 -0600
"Mike (mwester)" <mwester at dls.net> wrote:

> Paul Sokolovsky wrote:
> > Hello,
> >
> > On Sat, 09 Feb 2008 18:55:33 +0000
> > Richard Purdie <rpurdie at rpsys.net> wrote:
> >
> > []
> >
> >   
> >> The DISTRO can override the machine if it wishes now with no
> >> change to OE, that is up to the distros concerned. That doesn't
> >> stop machines from having sane defaults.
> >>
> >>     
> >>> Well, as usual, thoughts aloud. I'm going to add 
> >>> IMAGE_FSTYPES ?= "jffs2" to the machines from your 1st list to get
> >>> matter going.
> >>>       
> >> ok.
> >>
> >>     
> >
> > Done, so are we ready for this patch now?
> >
> >
> > @@ -541,7 +545,7 @@ DL_DIR ?= "${TMPDIR}/downloads" 
> >  ################################################################## 
> >   
> >  DL_DIR ?= "${TMPDIR}/downloads" 
> > -IMAGE_FSTYPES ?= "jffs2" 
> > +IMAGE_FSTYPES ?= "tar.gz" 
> >   
> Why exactly are we simply replacing a jffs2 default with a new
> default? Just to make some other parties happier?  

No, to make sure that probability of someone being unhappy and confused
is minimized. jffs2 is an adhoc, niche format, while tar.gz is
something well known. Getting tar.gz by default could be not exactly
what someone wants, but at least not something completely strange for
some people (consider x86 for example).

> Wouldn't it be
> simply better, if this is such a big deal, to do:
> 
> +IMAGE_FSTYPES ?=
> "you-must-define-an-image-fstype-that-is-suitable-for-you"
> 
> That way we ensure that *nobody* relies on defaults, and everything
> is correctly defined in every case, and if someone fails to define
> it, it should be pretty obvious what they did wrong.

This is exactly the opposite direction to what I'd like to move.
Configuring OE is already beyond capabilities of mere human, so many
people simply can't surpass initial setup curve of it, and other,
trying to help them, invent different adhoc solutions like
meta-makefiles. Our recent discussion exposed the fact that this is
pressing issue understood by many people, yet no good, well-fitting
solution was proposed. In this regard, I'm trying to follow my idea
that OE itself should change, first of all paradigmatically, to let
people use it "out of the box", without "extraordinary" effort required
to setup. For me, that means that OE should be usable immediately
after checkout of bitbake and itself, and adding bitbake to PATH. I've
been having such config for several months, and spooling my changes to
OE now.

So, with this idea, we want to have good, "not insane" defaults for
options, with the idea to offer our users easy learning curve on OE,
starting with it producing something easily visible and recognizable
by default, and then easy steps to tweak setup to get exactly what they
want.

[]
> >>     
> > Mike (mwester)
> >



-- 
Best regards,
 Paul                          mailto:pmiscml at gmail.com