[Buildroot] [PATCH 1/1] postgresql: remove devfiles from target

[Buildroot] [PATCH 1/1] postgresql: remove devfiles from target

[Floris Bos]

Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
---
 package/postgresql/postgresql.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/postgresql/postgresql.mk b/package/postgresql/postgresql.mk
index 0fecbc7..6d71b9c 100644
--- a/package/postgresql/postgresql.mk
+++ b/package/postgresql/postgresql.mk
@@ -51,6 +51,8 @@ endef
 
 define POSTGRESQL_INSTALL_TARGET_FIXUP
 	$(INSTALL) -dm 0700 $(TARGET_DIR)/var/lib/pgsql
+	rm -f $(TARGET_DIR)/usr/bin/pg_config
+	rm -rf $(TARGET_DIR)/usr/lib/postgresql/pgxs
 endef
 
 POSTGRESQL_POST_INSTALL_TARGET_HOOKS += POSTGRESQL_INSTALL_TARGET_FIXUP
-- 
1.8.3.2

[Buildroot] [PATCH 1/1] postgresql: remove devfiles from target

[Thomas De Schampheleire]

Floris Bos <bos@je-eigen-domein.nl> schreef:
>Signed-off-by: Floris Bos <bos@je-eigen-domein.nl>
>---
> package/postgresql/postgresql.mk | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/package/postgresql/postgresql.mk b/package/postgresql/postgresql.mk
>index 0fecbc7..6d71b9c 100644
>--- a/package/postgresql/postgresql.mk
>+++ b/package/postgresql/postgresql.mk
>@@ -51,6 +51,8 @@ endef
> 
> define POSTGRESQL_INSTALL_TARGET_FIXUP
> 	$(INSTALL) -dm 0700 $(TARGET_DIR)/var/lib/pgsql
>+	rm -f $(TARGET_DIR)/usr/bin/pg_config
>+	rm -rf $(TARGET_DIR)/usr/lib/postgresql/pgxs
> endef

Not entirely sure here, but isn't the better approach for pg_config to add it to POSTGRESQL_CONFIG_SCRIPTS? This will ensure the file is fixed up for staging usr, and removed from target automatically.

[Buildroot] [PATCH 1/1] postgresql: remove devfiles from target

[Floris Bos]

On 08/10/2014 09:01 AM, Thomas De Schampheleire wrote:
> define POSTGRESQL_INSTALL_TARGET_FIXUP
> 	$(INSTALL) -dm 0700 $(TARGET_DIR)/var/lib/pgsql
> +	rm -f $(TARGET_DIR)/usr/bin/pg_config
> +	rm -rf $(TARGET_DIR)/usr/lib/postgresql/pgxs
> endef
> Not entirely sure here, but isn't the better approach for pg_config to add it to POSTGRESQL_CONFIG_SCRIPTS? This will ensure the file is fixed up for staging usr, and removed from target automatically.
>

Note that pg_config is an ELF executable compiled for the target 
architecture, and not a text script that can be easily fixed up.


Yours sincerely,

Floris Bos

[Buildroot] [PATCH 1/1] postgresql: remove devfiles from target

[Thomas De Schampheleire]

Hi Floris,

On Sun, Aug 10, 2014 at 12:55 PM, Floris Bos <bos@je-eigen-domein.nl> wrote:
> On 08/10/2014 09:01 AM, Thomas De Schampheleire wrote:
>>
>> define POSTGRESQL_INSTALL_TARGET_FIXUP
>>         $(INSTALL) -dm 0700 $(TARGET_DIR)/var/lib/pgsql
>> +       rm -f $(TARGET_DIR)/usr/bin/pg_config
>> +       rm -rf $(TARGET_DIR)/usr/lib/postgresql/pgxs
>> endef
>> Not entirely sure here, but isn't the better approach for pg_config to add
>> it to POSTGRESQL_CONFIG_SCRIPTS? This will ensure the file is fixed up for
>> staging usr, and removed from target automatically.
>>
>
> Note that pg_config is an ELF executable compiled for the target
> architecture, and not a text script that can be easily fixed up.

Ok, in this case adding it to POSTGRESQL_CONFIG_SCRIPTS may not be the
best idea.

Best regards,
Thomas

[Buildroot] [PATCH 1/1] postgresql: remove devfiles from target

[Thomas Petazzoni]

Dear Thomas De Schampheleire,

On Sun, 10 Aug 2014 14:54:51 +0200, Thomas De Schampheleire wrote:

> >> Not entirely sure here, but isn't the better approach for pg_config to add
> >> it to POSTGRESQL_CONFIG_SCRIPTS? This will ensure the file is fixed up for
> >> staging usr, and removed from target automatically.
> >>
> >
> > Note that pg_config is an ELF executable compiled for the target
> > architecture, and not a text script that can be easily fixed up.
> 
> Ok, in this case adding it to POSTGRESQL_CONFIG_SCRIPTS may not be the
> best idea.

More precisely: it will simply not work. The <pkg>_CONFIG_SCRIPTS
mechanism assumes that the <pkg>-config files are shell scripts, in a
certain format. With an ELF executable compiled for the target:

 1/ There's no way the <pkg>_CONFIG_SCRIPTS mechanism can work

 2/ There's no real point in keeping this file on the build machine,
    because it's an executable built for the target.

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

[Buildroot] [PATCH 1/1] postgresql: remove devfiles from target

[Floris Bos]

Hi,

On 08/12/2014 06:50 PM, Thomas Petazzoni wrote:
> On Sun, 10 Aug 2014 14:54:51 +0200, Thomas De Schampheleire wrote:
>
>>>> Not entirely sure here, but isn't the better approach for pg_config to add
>>>> it to POSTGRESQL_CONFIG_SCRIPTS? This will ensure the file is fixed up for
>>>> staging usr, and removed from target automatically.
>>>>
>>> Note that pg_config is an ELF executable compiled for the target
>>> architecture, and not a text script that can be easily fixed up.
>> Ok, in this case adding it to POSTGRESQL_CONFIG_SCRIPTS may not be the
>> best idea.
> More precisely: it will simply not work. The <pkg>_CONFIG_SCRIPTS
> mechanism assumes that the <pkg>-config files are shell scripts, in a
> certain format. With an ELF executable compiled for the target:
>
>   1/ There's no way the <pkg>_CONFIG_SCRIPTS mechanism can work
>
>   2/ There's no real point in keeping this file on the build machine,
>      because it's an executable built for the target.

Do wonder if we shouldn't provide a simple replacement script for 
pg_config, e.g. just implementing "--includedir" and "--libdir"
Might be less work than patching configure scripts that want to call 
pg_config.


Yours sincerely,

Floris Bos

[Buildroot] [PATCH 1/1] postgresql: remove devfiles from target

[Thomas Petazzoni]

Dear Floris Bos,

On Tue, 12 Aug 2014 19:39:20 +0200, Floris Bos wrote:

> > More precisely: it will simply not work. The <pkg>_CONFIG_SCRIPTS
> > mechanism assumes that the <pkg>-config files are shell scripts, in a
> > certain format. With an ELF executable compiled for the target:
> >
> >   1/ There's no way the <pkg>_CONFIG_SCRIPTS mechanism can work
> >
> >   2/ There's no real point in keeping this file on the build machine,
> >      because it's an executable built for the target.
> 
> Do wonder if we shouldn't provide a simple replacement script for 
> pg_config, e.g. just implementing "--includedir" and "--libdir"
> Might be less work than patching configure scripts that want to call 
> pg_config.

Yes, that's certainly an option. If there are many packages relying on
pg_config, it's going to be easier to provide a fake pg_config rather
than patching all those packages (such as PHP). Maybe even this
approach could be submitted for upstream inclusion in Postgresql?

Best regards,

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

[Buildroot] [PATCH 1/1] postgresql: remove devfiles from target

[Floris Bos]

On 08/13/2014 09:26 AM, Thomas Petazzoni wrote:
> On Tue, 12 Aug 2014 19:39:20 +0200, Floris Bos wrote:
>
>>> More precisely: it will simply not work. The <pkg>_CONFIG_SCRIPTS
>>> mechanism assumes that the <pkg>-config files are shell scripts, in a
>>> certain format. With an ELF executable compiled for the target:
>>>
>>>    1/ There's no way the <pkg>_CONFIG_SCRIPTS mechanism can work
>>>
>>>    2/ There's no real point in keeping this file on the build machine,
>>>       because it's an executable built for the target.
>> Do wonder if we shouldn't provide a simple replacement script for
>> pg_config, e.g. just implementing "--includedir" and "--libdir"
>> Might be less work than patching configure scripts that want to call
>> pg_config.
> Yes, that's certainly an option. If there are many packages relying on
> pg_config, it's going to be easier to provide a fake pg_config rather
> than patching all those packages (such as PHP). Maybe even this
> approach could be submitted for upstream inclusion in Postgresql?

Convincing upstream to go back to a shell based pg_config might be 
difficult.
They actually had that at some point, but replaced it with the current 
application, because they needed a solution that also works on Windows 
(natively, without using Mingw/cygwin)

-- 
Yours sincerely,

Floris Bos