[Buildroot] Overriding Buildroot packages

[Buildroot] Overriding Buildroot packages

[Hajime Branko Yamasaki Vukelic]

Hi everyone!

I've set up my build such that all modification are done in
BR2_EXTERNAL directory, and I have a submodule that points to
unmodified upstream buildroot sources.

I've been trying to find a way to override a package that is normally
provided by Buildroot. By 'override' I mean completely swap it with
another package definition, possibly with different patches, etc.

Right now I've created a package that has a completely different name
(e.g., for package 'foo', I have 'foo-custom'), but this breaks
dependencies for packages that would otherwise depend on the original.

I've dug into pkg-generic.mk and I see that it may not really be
possible, but I wanted to confirm. Can someone tell me if I'm missing
something or this really isn't possible without modifying the
buildroot version of the package?

-- 
Branko
branko at brankovukelic.com

/dev/blog: brankovukelic.com

[Buildroot] Overriding Buildroot packages

[Thomas Petazzoni]

Hello,

On Tue, 24 Nov 2015 14:43:21 +0100, Hajime Branko Yamasaki Vukelic
wrote:

> I've set up my build such that all modification are done in
> BR2_EXTERNAL directory, and I have a submodule that points to
> unmodified upstream buildroot sources.
> 
> I've been trying to find a way to override a package that is normally
> provided by Buildroot. By 'override' I mean completely swap it with
> another package definition, possibly with different patches, etc.
> 
> Right now I've created a package that has a completely different name
> (e.g., for package 'foo', I have 'foo-custom'), but this breaks
> dependencies for packages that would otherwise depend on the original.
> 
> I've dug into pkg-generic.mk and I see that it may not really be
> possible, but I wanted to confirm. Can someone tell me if I'm missing
> something or this really isn't possible without modifying the
> buildroot version of the package?

This is really not possible with the current Buildroot, and would be
quite complicated to implement in a generic way.

If all you need is to apply a set of additional patches, then you can
do so without modifying the Buildroot package itself by using the
BR2_GLOBAL_PATCH_DIR mechanism.

However, if you indeed need a completely different version of the
package, we don't have a really good way of handling that.

Are you able to give more details about which specific package you need
to override and why? It would be useful for us to understand such use
cases, and see if there is a different solution/option, or if the use
case is really too specific.

Thanks!

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

[Buildroot] Overriding Buildroot packages

[Hajime Branko Yamasaki Vukelic]

Hi Thomas,

On Tue, Nov 24, 2015 at 4:41 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:

[SNIP]

> Are you able to give more details about which specific package you need
> to override and why? It would be useful for us to understand such use
> cases, and see if there is a different solution/option, or if the use
> case is really too specific.

I have a need to ship postgresql 9.5 beta instead of the stable 9.4.5.
Current solution is to create a postgres-95 package and modify
dependencies accordingly. Fortunately, this is currently just one
package, so it wasn't a big issue. Another package was bottle, on
which we gave up as not critical.

Ideally, ability to override some aspect of an existing package (e.g.,
only its version, or only the source URL, or something along those
lines) would be great to have. If not, then, a mechanism to make two
packages equivalent (something like virtual packages but applicaable
to packages that are not explicitly virtual) would also work (e.g.,
`POSTGRES_95_PROVIDES = postgres`, that causes having postgres-95
selected to satisfy dependency requirement for a package that
selects/depends on postgres).

-- 
Branko
branko at brankovukelic.com

/dev/blog: brankovukelic.com

[Buildroot] Overriding Buildroot packages

[Arnout Vandecappelle]

On 24-11-15 19:27, Hajime Branko Yamasaki Vukelic wrote:
> Hi Thomas,
> 
> On Tue, Nov 24, 2015 at 4:41 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
> 
> [SNIP]
> 
>> Are you able to give more details about which specific package you need
>> to override and why? It would be useful for us to understand such use
>> cases, and see if there is a different solution/option, or if the use
>> case is really too specific.
> 
> I have a need to ship postgresql 9.5 beta instead of the stable 9.4.5.
> Current solution is to create a postgres-95 package and modify
> dependencies accordingly. Fortunately, this is currently just one
> package, so it wasn't a big issue. Another package was bottle, on
> which we gave up as not critical.

 If the only thing you need to change is to use a different version, what I like
to do is to use OVERRIDE_SRCDIR instead of relying on the buildroot version. I
have a local.mk with:

# Create an automatic OVERRIDE for everything under src/
AUTO_OVERRIDES = $(notdir $(wildcard $(BR2_EXTERNAL)/src/*)))
do_override = $(1)_OVERRIDE_SRCDIR = $(BR2_EXTERNAL)/src/$(2)
$(foreach override,$(AUTO_OVERRIDES),\
        $(eval $(call do_override,$(call UPPERCASE,$(override)),$(override))))


(this snippet is licensed GPLv2+).


 The limitation of this approach is that you can't easily override other details
of the packaging, in particular the dependencies can't be overridden.

> 
> Ideally, ability to override some aspect of an existing package (e.g.,
> only its version, or only the source URL, or something along those
> lines) would be great to have. If not, then, a mechanism to make two
> packages equivalent (something like virtual packages but applicaable
> to packages that are not explicitly virtual) would also work (e.g.,
> `POSTGRES_95_PROVIDES = postgres`, that causes having postgres-95
> selected to satisfy dependency requirement for a package that
> selects/depends on postgres).

 There is a fairly easy way to make it possible to override the version and
dependencies, but I think it's a bit ugly. In inner-generic-package, instead of
defining all the rules directly, we could add yet another level of direction and
delay the definition of the rules until after BR2_EXTERNAL has been included.


 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] Overriding Buildroot packages

[Hajime Branko Yamasaki Vukelic]

On Tue, Nov 24, 2015 at 11:30 PM, Arnout Vandecappelle <arnout@mind.be> wrote:

[SNIP]

>> Ideally, ability to override some aspect of an existing package (e.g.,
>> only its version, or only the source URL, or something along those
>> lines) would be great to have. If not, then, a mechanism to make two
>> packages equivalent (something like virtual packages but applicaable
>> to packages that are not explicitly virtual) would also work (e.g.,
>> `POSTGRES_95_PROVIDES = postgres`, that causes having postgres-95
>> selected to satisfy dependency requirement for a package that
>> selects/depends on postgres).
>
>  There is a fairly easy way to make it possible to override the version and
> dependencies, but I think it's a bit ugly. In inner-generic-package, instead of
> defining all the rules directly, we could add yet another level of direction and
> delay the definition of the rules until after BR2_EXTERNAL has been included.

What if a package has <pkgname>.hash file? If I simply override the
version, wouldn't that still break when checking the hash?


-- 
Branko
branko at brankovukelic.com

/dev/blog: brankovukelic.com

[Buildroot] Overriding Buildroot packages

[Arnout Vandecappelle]

On 25-11-15 10:48, Hajime Branko Yamasaki Vukelic wrote:
> On Tue, Nov 24, 2015 at 11:30 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> 
> [SNIP]
> 
>>> Ideally, ability to override some aspect of an existing package (e.g.,
>>> only its version, or only the source URL, or something along those
>>> lines) would be great to have. If not, then, a mechanism to make two
>>> packages equivalent (something like virtual packages but applicaable
>>> to packages that are not explicitly virtual) would also work (e.g.,
>>> `POSTGRES_95_PROVIDES = postgres`, that causes having postgres-95
>>> selected to satisfy dependency requirement for a package that
>>> selects/depends on postgres).
>>
>>  There is a fairly easy way to make it possible to override the version and
>> dependencies, but I think it's a bit ugly. In inner-generic-package, instead of
>> defining all the rules directly, we could add yet another level of direction and
>> delay the definition of the rules until after BR2_EXTERNAL has been included.
> 
> What if a package has <pkgname>.hash file? If I simply override the
> version, wouldn't that still break when checking the hash?

 That's right, we'd need to find a workaround of that as well.

 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] Overriding Buildroot packages

[Yann E. MORIN]

On 2015-11-30 00:09 +0100, Arnout Vandecappelle spake thusly:
> On 25-11-15 10:48, Hajime Branko Yamasaki Vukelic wrote:
> > On Tue, Nov 24, 2015 at 11:30 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
> > 
> > [SNIP]
> > 
> >>> Ideally, ability to override some aspect of an existing package (e.g.,
> >>> only its version, or only the source URL, or something along those
> >>> lines) would be great to have. If not, then, a mechanism to make two
> >>> packages equivalent (something like virtual packages but applicaable
> >>> to packages that are not explicitly virtual) would also work (e.g.,
> >>> `POSTGRES_95_PROVIDES = postgres`, that causes having postgres-95
> >>> selected to satisfy dependency requirement for a package that
> >>> selects/depends on postgres).
> >>
> >>  There is a fairly easy way to make it possible to override the version and
> >> dependencies, but I think it's a bit ugly. In inner-generic-package, instead of
> >> defining all the rules directly, we could add yet another level of direction and
> >> delay the definition of the rules until after BR2_EXTERNAL has been included.
> > 
> > What if a package has <pkgname>.hash file? If I simply override the
> > version, wouldn't that still break when checking the hash?
> 
>  That's right, we'd need to find a workaround of that as well.

We already have a mechanism to avoid checking hashes;

    BR_NO_CHECK_HASH_FOR += tarball-name

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'