* [Buildroot] Overriding Buildroot packages @ 2015-11-24 13:43 Hajime Branko Yamasaki Vukelic 2015-11-24 15:41 ` Thomas Petazzoni 0 siblings, 1 reply; 7+ messages in thread From: Hajime Branko Yamasaki Vukelic @ 2015-11-24 13:43 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] Overriding Buildroot packages 2015-11-24 13:43 [Buildroot] Overriding Buildroot packages Hajime Branko Yamasaki Vukelic @ 2015-11-24 15:41 ` Thomas Petazzoni 2015-11-24 18:27 ` Hajime Branko Yamasaki Vukelic 0 siblings, 1 reply; 7+ messages in thread From: Thomas Petazzoni @ 2015-11-24 15:41 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] Overriding Buildroot packages 2015-11-24 15:41 ` Thomas Petazzoni @ 2015-11-24 18:27 ` Hajime Branko Yamasaki Vukelic 2015-11-24 22:30 ` Arnout Vandecappelle 0 siblings, 1 reply; 7+ messages in thread From: Hajime Branko Yamasaki Vukelic @ 2015-11-24 18:27 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] Overriding Buildroot packages 2015-11-24 18:27 ` Hajime Branko Yamasaki Vukelic @ 2015-11-24 22:30 ` Arnout Vandecappelle 2015-11-25 9:48 ` Hajime Branko Yamasaki Vukelic 0 siblings, 1 reply; 7+ messages in thread From: Arnout Vandecappelle @ 2015-11-24 22:30 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] Overriding Buildroot packages 2015-11-24 22:30 ` Arnout Vandecappelle @ 2015-11-25 9:48 ` Hajime Branko Yamasaki Vukelic 2015-11-29 23:09 ` Arnout Vandecappelle 0 siblings, 1 reply; 7+ messages in thread From: Hajime Branko Yamasaki Vukelic @ 2015-11-25 9:48 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] Overriding Buildroot packages 2015-11-25 9:48 ` Hajime Branko Yamasaki Vukelic @ 2015-11-29 23:09 ` Arnout Vandecappelle 2015-12-05 17:29 ` Yann E. MORIN 0 siblings, 1 reply; 7+ messages in thread From: Arnout Vandecappelle @ 2015-11-29 23:09 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* [Buildroot] Overriding Buildroot packages 2015-11-29 23:09 ` Arnout Vandecappelle @ 2015-12-05 17:29 ` Yann E. MORIN 0 siblings, 0 replies; 7+ messages in thread From: Yann E. MORIN @ 2015-12-05 17:29 UTC (permalink / raw) To: buildroot 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. | '------------------------------^-------^------------------^--------------------' ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-12-05 17:29 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-24 13:43 [Buildroot] Overriding Buildroot packages Hajime Branko Yamasaki Vukelic 2015-11-24 15:41 ` Thomas Petazzoni 2015-11-24 18:27 ` Hajime Branko Yamasaki Vukelic 2015-11-24 22:30 ` Arnout Vandecappelle 2015-11-25 9:48 ` Hajime Branko Yamasaki Vukelic 2015-11-29 23:09 ` Arnout Vandecappelle 2015-12-05 17:29 ` Yann E. MORIN
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.