[Buildroot] How handle broken or partly broken packages in the distribution

[Buildroot] How handle broken or partly broken packages in the distribution

[Ulf Samuelsson]

The following packages will not build for the AVR32
since it is not supported as an architecture.
or dependencies cause the same problem:

bberkeleydb
kexec
libevent
ltrace
argus
bind
kismet
libeXosip2
ntpd
openvpn
stunnel
vtun
dbus-glib
dmraid
hal
ntfs-3g
smartmontools
ruby
xerces


I suggest we disable them using
	depends on "BR2_avr32

so they are not selectable for AVR32 users

BR
Ulf Samuelsson

[Buildroot] How handle broken or partly broken packages in the distribution

[Hans-Christian Egtvedt]

On Thu, 22 Jan 2009 20:07:33 +0100
Ulf Samuelsson <ulf.samuelsson@atmel.com> wrote:

<snipp list of packages>
 
> I suggest we disable them using
> 	depends on "BR2_avr32
> 

I assume " was supposed to be !.

> so they are not selectable for AVR32 users
> 

To make it harder to fix the problem with the packages?

It might also be a result from the development environment on your
build machine, like the recent alsa-utils errors somebody else found on
opensuse, which I have not triggered in my Ubuntu system.

-- 
Best regards,
Hans-Christian Egtvedt

[Buildroot] How handle broken or partly broken packages in the distribution

[Ulf Samuelsson]

fre 2009-01-23 klockan 09:57 +0100 skrev Hans-Christian Egtvedt:
> On Thu, 22 Jan 2009 20:07:33 +0100
> Ulf Samuelsson <ulf.samuelsson@atmel.com> wrote:
> 
> <snipp list of packages>
>  
> > I suggest we disable them using
> > 	depends on "BR2_avr32
> > 
> 
> I assume " was supposed to be !.
> 

Of course.

> > so they are not selectable for AVR32 users
> > 
> 
> To make it harder to fix the problem with the packages?
> 

No, I think the distribution should as a default only enable things
which actually has a slim change to build.

The svn should allow developers more freedom.

> It might also be a result from the development environment on your
> build machine, like the recent alsa-utils errors somebody else found on
> opensuse, which I have not triggered in my Ubuntu system.
> 

True, but that was why I sent is as a suggestion.
These packages looks terminally broken to me for the AVR32.
If we know that they are broken then we should not expose
inexperienced firstcomers to Buildroot to them.

A package which depends on the build host should not be
disabled or at least not in this manner.

If we want more users/contributors, then the behaviour
should be perceived as stable, and we currently have 
no mechanism to ensure stability.


BR
Ulf Samuelsson

[Buildroot] How handle broken or partly broken packages in the distribution

[Ulf Samuelsson]

fre 2009-01-23 klockan 09:57 +0100 skrev Hans-Christian Egtvedt:
> On Thu, 22 Jan 2009 20:07:33 +0100
> Ulf Samuelsson <ulf.samuelsson@atmel.com> wrote:
> 
> <snipp list of packages>
>  
> > I suggest we disable them using
> > 	depends on "BR2_avr32
> > 
> 
> I assume " was supposed to be !.
> 
> > so they are not selectable for AVR32 users
> > 
> 
> To make it harder to fix the problem with the packages?
> 
> It might also be a result from the development environment on your
> build machine, like the recent alsa-utils errors somebody else found on
> opensuse, which I have not triggered in my Ubuntu system.
> 

True in some cases, but if the "machine is not recognized" 
pops up, then there is a slim chance for it to build.

An alternative approach would be to depend on 

	!BR_PACKAGE_<XXXX>_HIDE

and have
config BR2_HIDE_BROKEN_ON_AVR32
	depends on BR2_avr32
?	 select ?BR_PACKAGE_<XXX1>_HIDE?
	select ?BR_PACKAGE_<XXX1>_HIDE
	select ?BR_PACKAGE_<XXX1>_HIDE
	select ?BR_PACKAGE_<XXX1>_HIDE
	etc.
 
Which packages should be disabled this way should be open for
discussion, but if noone can build it, there
is no reason for wasting everyones time by making
it visible IN THE DISTRIBUTION.

BR
Ulf Samuelsson

[Buildroot] How handle broken or partly broken packages in the distribution

[Thiago A. Corrêa]

Ulf,

On Fri, Jan 23, 2009 at 6:57 AM, Hans-Christian Egtvedt
<hans-christian.egtvedt@atmel.com> wrote:
>> so they are not selectable for AVR32 users
>>
>
> To make it harder to fix the problem with the packages?
>
> It might also be a result from the development environment on your
> build machine, like the recent alsa-utils errors somebody else found on
> opensuse, which I have not triggered in my Ubuntu system.
>

I agree with HCE. Making packages unselectable or invisible is not a
good approach.
I think it would be very sufficient to just document it on the help
string and take it out of the defconfig for that arch.

Kind Regards,
   Thiago A. Correa

[Buildroot] How handle broken or partly broken packages in the distribution

[Ulf Samuelsson]

fre 2009-01-23 klockan 15:12 -0200 skrev Thiago A. Corr?a:
> Ulf,
> 
> On Fri, Jan 23, 2009 at 6:57 AM, Hans-Christian Egtvedt
> <hans-christian.egtvedt@atmel.com> wrote:
> >> so they are not selectable for AVR32 users
> >>
> >
> > To make it harder to fix the problem with the packages?
> >
> > It might also be a result from the development environment on your
> > build machine, like the recent alsa-utils errors somebody else found on
> > opensuse, which I have not triggered in my Ubuntu system.
> >
> 
> I agree with HCE. Making packages unselectable or invisible is not a
> good approach.
> I think it would be very sufficient to just document it on the help
> string and take it out of the defconfig for that arch.

It is sufficient for experienced buildroot user,
but for people *starting* to use it, then they 
have to experiment and spend a lot of time 
trying to figure out what works and what does not work.

Why on earth do you want to enable a thing which NEVER will work?

If you want to update the package so it works,
then you can do that in the trunk which should not 
have these limitations turned on by default 

The distibution, on the other hand, should be easy to use
and should IMO protect users against wasting their time.

BR
Ulf Samuelsson

> Kind Regards,
>    Thiago A. Correa
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] How handle broken or partly broken packages in the distribution

[Thiago A. Corrêa]

On Fri, Jan 23, 2009 at 3:46 PM, Ulf Samuelsson
<ulf.samuelsson@atmel.com> wrote:
>
> Why on earth do you want to enable a thing which NEVER will work?
>
> If you want to update the package so it works,
> then you can do that in the trunk which should not
> have these limitations turned on by default

As I said, just remove the package from defconfig.
If we start disabling stuff just because of some minor build problem,
the chances that it will be fixed and enabled again are slim. How do
you differentiate things that are just minor corrections from things
that doesn't make sense at all to be enabled in that platform?

We would of course want to disable PCI Utils in AVR32 since there is
no PCI bus there. But not linux-fusion stuff that doesn't build right
now but it did a while back.

Usually a release is a trunk revision at some point. Going thru
several packages disabling them just for releases isn't much
practical.

> The distibution, on the other hand, should be easy to use
> and should IMO protect users against wasting their time.

They can read the help message for that. A common pattern for users is
to build the default config first, and that we should make sure to
have working.


Kind Regards,
    Thiago A. Correa

[Buildroot] How handle broken or partly broken packages in the distribution

[Ulf Samuelsson]

fre 2009-01-23 klockan 19:17 -0200 skrev Thiago A. Corr?a:
> On Fri, Jan 23, 2009 at 3:46 PM, Ulf Samuelsson
> <ulf.samuelsson@atmel.com> wrote:
> >
> > Why on earth do you want to enable a thing which NEVER will work?
> >
> > If you want to update the package so it works,
> > then you can do that in the trunk which should not
> > have these limitations turned on by default
> 
> As I said, just remove the package from defconfig.

You do not get it.
It is not for MY purpose I want it removed in DISTRIBUTION.
I want to disable it in the DISTRIBUTION so that people
that download the DISTRIBUTION will not run into unneccessary trouble.

People downloading the TRUNK or a DAILY BUILD of the TRUNK
will not see these packages as disabled.

> If we start disabling stuff just because of some minor build problem,
> the chances that it will be fixed and enabled again are slim. How do
> you differentiate things that are just minor corrections from things
> that doesn't make sense at all to be enabled in that platform?

?
we are talking about packages which has NEVER worked because
the inherent support for the AVR32 is simply not there.
For other packages, we simply have to get consensus
if it makes sense or not to disable.

If it works when compiling on Ubuntu, but not on OpenSuSE
then this should be documented as a bug for OpenSuSE.
If noone can complete the build for anything, why allow is.

An example is Irda-utils. The irda-utils.mk is garbled.
Do you still think it makes sense to enable it in the
DISTRIBUTION (will be enabled in TRUNK)


> 
> We would of course want to disable PCI Utils in AVR32 since there is
> no PCI bus there. But not linux-fusion stuff that doesn't build right
> now but it did a while back.

Pls distinguish between DISTRIBUTION and TRUNK.

> Usually a release is a trunk revision at some point. Going thru
> several packages disabling them just for releases isn't much
> practical.

I disagree, the amount of work to do this, is much less work
than the amount of works wasted because the function is not there.

You have one file which contains 
	
config	BR2_AVR32_DISABLE
	depends on BR2_avr32
	select BR2_PACKAGE_<XXX>_DISABLE
	select BR2_PACKAGE_<YYY>_DISABLE
	...
	select BR2_PACKAGE_<ZZZ>_DISABLE

This can be automatically generated from a file.

Each package needs

config	BR2_PACKAGE_XXX
	depends on !?BR2_PACKAGE_<XXX>_DISABLE

This is created once and for all.

> > The distibution, on the other hand, should be easy to use
> > and should IMO protect users against wasting their time.
> 
> They can read the help message for that. 

There will be more maintenace creating help messages for
each target than to create a file which deselects packages.
The latter can be easily automated, the former will be 
more difficult.

> A common pattern for users is
> to build the default config first, and that we should make sure to
> have working.
> 

I agree here but very few will be able to use the defconfig for their
own project, and will QUICKLY run into problems and will 
consider the project inmature/useless.

There is a lot of research into user interface, and people
do not like systems that cause them unneccessary hassle.
Buildroot is currently a PITA for new users.

A proper distribution with a mirror server could change that,
but I have yet to see any improvement in the methodology
to improve stability.

?I provided test results for ARM and AVR32.
Where are the tests for PowerPC, MIPS, x86 etc...
?I also do not see a list of tested boards anywhere.

The test results should be documented and provided 
as part of the distribution.

Until that happens I am not confident that 
we are ready to release the distribution.

> 
> Kind Regards,
>     Thiago A. Correa
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

[Buildroot] How handle broken or partly broken packages in the distribution

[Hans-Christian Egtvedt]

On Fri, 23 Jan 2009 15:12:56 -0200
Thiago A. Corr?a <thiago.correa@gmail.com> wrote:

> On Fri, Jan 23, 2009 at 6:57 AM, Hans-Christian Egtvedt
> <hans-christian.egtvedt@atmel.com> wrote:
> >> so they are not selectable for AVR32 users
> >>
> >
> > To make it harder to fix the problem with the packages?
> >
> > It might also be a result from the development environment on your
> > build machine, like the recent alsa-utils errors somebody else
> > found on opensuse, which I have not triggered in my Ubuntu system.
> >
> 
> I agree with HCE. Making packages unselectable or invisible is not a
> good approach.
> I think it would be very sufficient to just document it on the help
> string and take it out of the defconfig for that arch.
> 

Or just have a Wiki with a list of all packages and which archs they
work and do not work on. Users should also see/find this table fast, so
they easily know what is expected to work and what is not.

It might even encourage users to start fiddling with packages not
working.

-- 
Best regards,
Hans-Christian Egtvedt