Le 28/10/2017 à 01:47, Jason L Tibbitts III a écrit :
A new section was added to the packaging guidelines regarding shebang lines. It forbids the use of 'env' and codifies the longstanding rpmlint rule that non-executable files should not have shebang lines.
I strongly disapproved this new forbidden use of env.
It works perfectly and have lot of benefits, at least for SCL users, especially for PHP stack where compatibility is very good between version.
Yes, I have a huge usage of multi-versions of the language installed and used simultaneously.
Switching back to hard coded path to PHP binary will be, IMHO, a huge regression for PHP developers.
I won't change any of my package.
Remi.
On Wed, Nov 1, 2017 at 12:32 PM, Remi Collet Fedora@famillecollet.com wrote:
Le 28/10/2017 à 01:47, Jason L Tibbitts III a écrit :
A new section was added to the packaging guidelines regarding shebang lines. It forbids the use of 'env' and codifies the longstanding rpmlint rule that non-executable files should not have shebang lines.
I strongly disapproved this new forbidden use of env.
It works perfectly and have lot of benefits, at least for SCL users, especially for PHP stack where compatibility is very good between version.
Yes, I have a huge usage of multi-versions of the language installed and used simultaneously.
Switching back to hard coded path to PHP binary will be, IMHO, a huge regression for PHP developers.
I won't change any of my package.
The problem is that while it might be fine for PHP stuff, it's not usually fine for Ruby, Python, or anything else.
And really, what we need is a brp script in rpm to rewrite it transparently, so that it matches whatever interpreter it's supposed to run with.
"NG" == Neal Gompa ngompa13@gmail.com writes:
NG> The problem is that while it might be fine for PHP stuff, it's not NG> usually fine for Ruby, Python, or anything else.
It's not fine anywhere. If I put a link or whatever in my personal bin directory and then a system-installed package breaks, that's a bug. It's still a bug even if I link ~/bin/php to /bin/false; compatibility between PHP versions makes no difference.
NG> And really, what we need is a brp script in rpm to rewrite it NG> transparently, so that it matches whatever interpreter it's supposed NG> to run with.
Yes, it would be nice if this could just be handled automatically so people didn't have to think about it. I don't really know how practical that is, though.
- J<
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On Wed, 2017-11-01 at 12:39 -0500, Jason L Tibbitts III wrote:
[...]
NG> And really, what we need is a brp script in rpm to rewrite it NG> transparently, so that it matches whatever interpreter it's supposed NG> to run with.
Yes, it would be nice if this could just be handled automatically so people didn't have to think about it. I don't really know how practical that is, though.
This would allow packagers to remove their sed scripts... $ grep "sed.*/env" *.spec -l | wc -l 353
Also it would fix packages dependent on /usr/bin/env automagically.. $ sudo dnf repoquery --whatrequires /usr/bin/env --exactdeps 2>/dev/null | wc -l 1263 - -- - -Igor Gnatenko
Le 01/11/2017 à 18:39, Jason L Tibbitts III a écrit :
It's not fine anywhere. If I put a link or whatever in my personal bin directory and then a system-installed package breaks, that's a bug.
Ok, so consistency, using same logic, please make RPATH usage mandatory to ensure the proper libraries are used by all the packaged applications.
Remi
P.S. despite I never have any bug filed for issue with /usr/bin/env, I recently get one about library, #1505101
"RC" == Remi Collet Fedora@FamilleCollet.com writes:
RC> Ok, so consistency, using same logic, please make RPATH usage RC> mandatory to ensure the proper libraries are used by all the RC> packaged applications.
Well, I'll raise two points:
* You are certainly free to submit a draft. That may be a reasonable thing to do but I haven't put any thought into it and I don't know how difficult it is. Which brings me to....
* Perfect is the enemy of good. Sometimes we do good things that are easy (like fixing one line at the top of executable scripts) even though it's not a 100% solution or doesn't cover all similar cases.
- J<
On Thu, Nov 02, 2017 at 07:19:18AM +0100, Remi Collet wrote:
It's not fine anywhere. If I put a link or whatever in my personal bin directory and then a system-installed package breaks, that's a bug.
Ok, so consistency, using same logic, please make RPATH usage mandatory to ensure the proper libraries are used by all the packaged applications.
I don't think this is really a comparable situation, as we don't put /usr/local before system paths for library searches, but we *do* by default for PATH.
I think this really highlights a problem with packaging dynamic language stacks overall. Are they being packaged to support applications in the distribution proper? Or, are they being packaged to support end-user development and applications? Right now, our answer is "everything at once", and that leads to friction.
Remi, the Modularity answer here would be to automatically (that is, with one command and from one spec file) build the packages for different bases. Would this address your concerns?
Hello, Remi.
On Wednesday, 01 November 2017 at 17:32, Remi Collet wrote:
Le 28/10/2017 à 01:47, Jason L Tibbitts III a écrit :
A new section was added to the packaging guidelines regarding shebang lines. It forbids the use of 'env' and codifies the longstanding rpmlint rule that non-executable files should not have shebang lines.
I strongly disapproved this new forbidden use of env.
You're welcome to bring the issue back to the FPC and present new arguments.
It works perfectly and have lot of benefits, at least for SCL users,
SCLs are not part of Fedora.
especially for PHP stack where compatibility is very good between version.
Yes, I have a huge usage of multi-versions of the language installed and used simultaneously.
I don't see any parallel-installable php engine packages in Fedora, so I'm not sure I see your point.
If you meant EPEL, then you're welcome to talk to EPSCo about changing the rules for EPEL only.
Switching back to hard coded path to PHP binary will be, IMHO, a huge regression for PHP developers.
I won't change any of my package.
Sorry, Remi, but that's just hostile and uncooperative for no good reason. Please calm down so that we can have a reasonable discussion.
Did you forget https://getfedora.org/code-of-conduct ?
Regards, Dominik
Le 02/11/2017 à 00:52, Dominik 'Rathann' Mierzejewski a écrit :
Switching back to hard coded path to PHP binary will be, IMHO, a huge regression for PHP developers.
I won't change any of my package.
Sorry, Remi, but that's just hostile and uncooperative for no good reason. Please calm down so that we can have a reasonable discussion.
I'm very calm I have explained why I think this change is bad.
I don't see any hostility here.
Remi
Did you forget https://getfedora.org/code-of-conduct ?
Regards, Dominik
Le 02/11/2017 à 00:52, Dominik 'Rathann' Mierzejewski a écrit :
You're welcome to bring the issue back to the FPC and present new arguments.
packaging@lists.fedoraproject.org
-
Dominik 'Rathann' Mierzejewski -
Igor Gnatenko -
Jason L Tibbitts III -
Matthew Miller -
Neal Gompa -
Remi Collet