[Buildroot] [PATCH] at45-split (2/3)1

[Buildroot] [PATCH] at45-split (2/3)1

[Ulf Samuelsson]

>>
>>Thanks and sorry for the delay.
>>
>>PS: I'm aware of your Board support builddir patch, that i didn't look
>>at yet, are there any other pending patches i managed to miss?
>>

There is actually one more.
The "local" patch.

Eric NAK'ed this patch, due to "duplication" with "package/customize"
so I reworked the patch by removing "package/customize"
and putting the functionality into the "local" directory.

For maintenance reasons, I find it important that this stuff is in at the 
top level.
The "local" directory is a place holder for the users
packages/ which he/she never plans to submit to
the mainstream, and it is just a pain to have it
inside the package directory.

Once the patch is there, you can download the latest version
and then copy your own local directory into the buildroot tree.
This will replace the contencts of the "local" directory
and you do not have to patch toplevel Makefile or Config.in.
(A symbolic link from "local" to an out of tree directory will also do)

If you read the comments from everyone but Eric,
I think you find that everyone else is positive to the patch.
I have had several off-line mails from people that support the idea.


The patch will also update the /etc/hostname
from the BR2_BOARDNAME in the BSP patch.
(Maybe it shodul change name to BR2_HOSTNAME?)
and allow the developer to provide his/her own welcome banner.


Best Regards
Ulf Samuelsson

[Buildroot] [PATCH] at45-split (2/3)1

[Bernhard Fischer]

On Fri, Feb 09, 2007 at 08:29:54PM +0100, Ulf Samuelsson wrote:
>
>>>
>>>Thanks and sorry for the delay.
>>>
>>>PS: I'm aware of your Board support builddir patch, that i didn't look
>>>at yet, are there any other pending patches i managed to miss?
>>>
>
>There is actually one more.
>The "local" patch.
>
>Eric NAK'ed this patch, due to "duplication" with "package/customize"
>so I reworked the patch by removing "package/customize"
>and putting the functionality into the "local" directory.
>
>For maintenance reasons, I find it important that this stuff is in at the 
>top level.
>The "local" directory is a place holder for the users
>packages/ which he/she never plans to submit to
>the mainstream, and it is just a pain to have it

and that's unfortunately the reason why i, personally, dislike it.

Why would you want me or anybody else that contributes to publically
visible areas to maintain your base if those people who devote their
rare spare-time to support a proper working base to be closed out from
improvements? This project is about collaboration and doesn't aim at
providing a convenience gate between closed areas like drivers
/ specs and the rest of e.g. the kernel-API but for userspace which is --
in the area of this project GPL, AFAICS.

I'm not too keen on playing the maintenance clerk anybody shouts at if
one drops an old version, but that local patch aims at exactly this area
of non-fun, at least in MHO.

Guess i just fail to see the benefit that'd impose, generally.

How does the "local patch" help e.g. me (to achieve what) ? 

>inside the package directory.
>
>Once the patch is there, you can download the latest version
>and then copy your own local directory into the buildroot tree.
>This will replace the contencts of the "local" directory
>and you do not have to patch toplevel Makefile or Config.in.
>(A symbolic link from "local" to an out of tree directory will also do)
>
>If you read the comments from everyone but Eric,
>I think you find that everyone else is positive to the patch.
>I have had several off-line mails from people that support the idea.

I can imagine that, yes ;)
>
>The patch will also update the /etc/hostname
>from the BR2_BOARDNAME in the BSP patch.
>(Maybe it shodul change name to BR2_HOSTNAME?)

A BR2_HOSTNAME that defaults to the board short of a user-configured
name sounds fine to me.
>and allow the developer to provide his/her own welcome banner.

Sure.

[Buildroot] [PATCH] at45-split (2/3)1

[Ulf Samuelsson]

> On Fri, Feb 09, 2007 at 08:29:54PM +0100, Ulf Samuelsson wrote:
>>
>>>>
>>>>Thanks and sorry for the delay.
>>>>
>>>>PS: I'm aware of your Board support builddir patch, that i didn't look
>>>>at yet, are there any other pending patches i managed to miss?
>>>>
>>
>>There is actually one more.
>>The "local" patch.
>>
>>Eric NAK'ed this patch, due to "duplication" with "package/customize"
>>so I reworked the patch by removing "package/customize"
>>and putting the functionality into the "local" directory.
>>
>>For maintenance reasons, I find it important that this stuff is in at the
>>top level.
>>The "local" directory is a place holder for the users
>>packages/ which he/she never plans to submit to
>>the mainstream, and it is just a pain to have it
>
> and that's unfortunately the reason why i, personally, dislike it.
>
> Why would you want me or anybody else that contributes to publically
> visible areas to maintain your base if those people who devote their
> rare spare-time to support a proper working base to be closed out from
> improvements? This project is about collaboration and doesn't aim at
> providing a convenience gate between closed areas like drivers
> / specs and the rest of e.g. the kernel-API but for userspace which is --
> in the area of this project GPL, AFAICS.
>

Since I work as an FAE,  I don't have a "base".
I don't build and deliver commercial stuff to people.
I am happy to provide everything I generate to the public,
but I do not think that, for instance, a small application
written to stress the chip to increase the rate of occurance of a H/W bug
is of great interest to people downloading buildroot.

There is stuff which simply does not belong in the mainstream buildroot.

The patch can be used to maintain closed source, and sometimes
this can be for valid reasons and sometimes for not so valid reasons.

I know that people atre maintaining "local" directories in their own
versions of buildroot and this is a simple way of helping them out.

My main benefit of this patch, is that I hope there will be less
people calling in to ask questions if I make things so easy
that no questions are needed.

The current buildroot already has this functionality in the
packages/customize directory so Eric acknowledges the need
already, he just did not like to duplicate it.

The new patch removes the duplication by moving
the "package/customize" functionality to "local".


> I'm not too keen on playing the maintenance clerk anybody shouts at if
> one drops an old version, but that local patch aims at exactly this area
> of non-fun, at least in MHO.
>
> Guess i just fail to see the benefit that'd impose, generally.
>
> How does the "local patch" help e.g. me (to achieve what) ?
>

Assume that I am developing a new source package.
I want to include the binaries into a file system generated by buildroot.
The source package is not in a releasable state.
I.E: is it so buggy that releasing the stuff will generate so many
questions that further development will be slowed down by releasing it.

You then decide of other reasons to upgrade your buildroot lets say on 
another machine..
How do you transfer the stuff from the previous buildroot.

With my patch you can drag and drop the stuff from one buildroot directory
to another.

You can do this with the package/customize directory as well
but it is easier if this is at the top level.

>>inside the package directory.
>>
>>Once the patch is there, you can download the latest version
>>and then copy your own local directory into the buildroot tree.
>>This will replace the contencts of the "local" directory
>>and you do not have to patch toplevel Makefile or Config.in.
>>(A symbolic link from "local" to an out of tree directory will also do)
>>
>>If you read the comments from everyone but Eric,
>>I think you find that everyone else is positive to the patch.
>>I have had several off-line mails from people that support the idea.
>
> I can imagine that, yes ;)
>>
>>The patch will also update the /etc/hostname
>>from the BR2_BOARDNAME in the BSP patch.
>>(Maybe it shodul change name to BR2_HOSTNAME?)
>
> A BR2_HOSTNAME that defaults to the board short of a user-configured
> name sounds fine to me.
>>and allow the developer to provide his/her own welcome banner.
>
> Sure.
>


Best Regards
Ulf Samuelsson