[Buildroot] Howto handle fork of an existing package

[Buildroot] Howto handle fork of an existing package

[Atilla Filiz]

Hello

I have made a package of Wiring Pi for Lemaker boards Banana Pi and 
Banana Pro. Since this is a fork from an older version, the site, teh 
versioning, the patches etc are all different. I would like to ask, 
whoat would be the best way to merge this package properly. Either

1. Make it a completely new package, like wiringpi-lemaker and make it 
depend on !BR2_PACKAGE_WIRINGPI and vice versa. Easiest way.

2. Turn wiringpi into a subtree, with a radio button for board 
selection: Raspberry Pi, Banana Pi, Banana Pro and enable teh proper 
package. Raspberry Pi being the default option. Slightly intrusive way.

3. Have one wiringpi to rule them all. Make the board selection as a 
mere set of parameters. Make a bit more complicated wirinpi.mk that 
selects correct site, version, patch directory etc depending on a bunch 
of defined flags. Possibly unnecessarily complicated.

Currently I made and tested it as a separate package.

Atilla

[Buildroot] Howto handle fork of an existing package

[Thomas Petazzoni]

Hello,

On Fri, 4 Aug 2017 14:21:26 +0200, Atilla Filiz wrote:

> I have made a package of Wiring Pi for Lemaker boards Banana Pi and 
> Banana Pro. Since this is a fork from an older version, the site, teh 
> versioning, the patches etc are all different. I would like to ask, 
> whoat would be the best way to merge this package properly. Either
> 
> 1. Make it a completely new package, like wiringpi-lemaker and make it 
> depend on !BR2_PACKAGE_WIRINGPI and vice versa. Easiest way.
> 
> 2. Turn wiringpi into a subtree, with a radio button for board 
> selection: Raspberry Pi, Banana Pi, Banana Pro and enable teh proper 
> package. Raspberry Pi being the default option. Slightly intrusive way.
> 
> 3. Have one wiringpi to rule them all. Make the board selection as a 
> mere set of parameters. Make a bit more complicated wirinpi.mk that 
> selects correct site, version, patch directory etc depending on a bunch 
> of defined flags. Possibly unnecessarily complicated.

4. Contribute to the official wiringpi project instead of doing a fork,
so that a single project supports multiple platforms.

I think I have a preference for option (4). If not possible, option (3)
will be acceptable, but not as nice :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Howto handle fork of an existing package

[Arnout Vandecappelle]

On 04-08-17 16:41, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 4 Aug 2017 14:21:26 +0200, Atilla Filiz wrote:
> 
>> I have made a package of Wiring Pi for Lemaker boards Banana Pi and 
>> Banana Pro. Since this is a fork from an older version, the site, teh 
>> versioning, the patches etc are all different. I would like to ask, 
>> whoat would be the best way to merge this package properly. Either
>>
>> 1. Make it a completely new package, like wiringpi-lemaker and make it 
>> depend on !BR2_PACKAGE_WIRINGPI and vice versa. Easiest way.
>>
>> 2. Turn wiringpi into a subtree, with a radio button for board 
>> selection: Raspberry Pi, Banana Pi, Banana Pro and enable teh proper 
>> package. Raspberry Pi being the default option. Slightly intrusive way.
>>
>> 3. Have one wiringpi to rule them all. Make the board selection as a 
>> mere set of parameters. Make a bit more complicated wirinpi.mk that 
>> selects correct site, version, patch directory etc depending on a bunch 
>> of defined flags. Possibly unnecessarily complicated.
> 
> 4. Contribute to the official wiringpi project instead of doing a fork,
> so that a single project supports multiple platforms.

 Tell that to the LeMaker people, not to Atilla. And while you're at it, tell
the RaspberryPi people to not fork the kernel interfaces so that there is no
need to create a library that has to be forked for RaspberryPi-derivatives...


> I think I have a preference for option (4). If not possible, option (3)
> will be acceptable, but not as nice :-)

 Essentially there is no real relationship between the proprietary GPIO
interface for RPi and the *different* proprietary GPIO interface for BPi, so I
wouldn't mind solution (1). It's a different upstream with a potentially
different API...

 By the way, upstream says:
"This is a modified WiringPi for Banana Pro/Pi. We call it WiringBP."
So naturally, the package should be called wiringbp.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Howto handle fork of an existing package

[Atilla Filiz]

On 08/04/2017 06:41 PM, Arnout Vandecappelle wrote:
>
> On 04-08-17 16:41, Thomas Petazzoni wrote:
>>
>> 4. Contribute to the official wiringpi project instead of doing a fork,
>> so that a single project supports multiple platforms.
>   Tell that to the LeMaker people, not to Atilla. And while you're at it, tell
> the RaspberryPi people to not fork the kernel interfaces so that there is no
> need to create a library that has to be forked for RaspberryPi-derivatives...
It is not only up to Lemaker, as WiringPi website says although forks 
are encouraged, only Raspberry Pi is officially supported. They do not 
intend to support anything else.
>> I think I have a preference for option (4). If not possible, option (3)
>> will be acceptable, but not as nice :-)
>   Essentially there is no real relationship between the proprietary GPIO
> interface for RPi and the *different* proprietary GPIO interface for BPi, so I
> wouldn't mind solution (1). It's a different upstream with a potentially
> different API...
>
>   By the way, upstream says:
> "This is a modified WiringPi for Banana Pro/Pi. We call it WiringBP."
> So naturally, the package should be called wiringbp.
Good point. I will test and submit a proper patch as wiringbp. Thank you 
both.

Regards
Atilla