[gentoo-dev] Last rites EAPI=6 packages: dev-php/*

[gentoo-dev] Last rites EAPI=6 packages: dev-php/*

[Arthur Zamarin]

[-- Attachment #1.1: Type: text/plain, Size: 655 bytes --]

# Arthur Zamarin <arthurzam@gentoo.org> (2024-06-21)
# Last dev-php/* EAPI=6 packages, and reverse dependencies of them.
# composer has active security vulnerabilities. Others are waiting
# for version bumps, and unbundling of dependencies.
# Removal on 2024-07-21.  Bugs #934666.
dev-php/phpDocumentor
dev-php/phpcov
dev-php/phpdepend
dev-php/phpdocumentor-reflection-common
dev-php/phpdocumentor-reflection-docblock
dev-php/phpdocumentor-type-resolver
dev-php/stringparser_bbcode
dev-php/symfony-config
dev-php/symfony-console
dev-php/symfony-dependency-injection
dev-php/symfony-event-dispatcher
dev-php/symfony-yaml
dev-php/composer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

[Jaco Kroon]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

Hi,

I missed this announcement, looking specifically for composer again.

If I make the effort of bumping to newest version, is this something 
that would be re-added to the tree?

I note there were active security vulnerabilities under very specific 
conditions (composer.phar is exposed via http).

Or should I rather just deploy this into a local overlay?

Kind regards,
Jaco


On 2024/06/21 19:20, Arthur Zamarin wrote:
> # Arthur Zamarin<arthurzam@gentoo.org>  (2024-06-21)
> # Last dev-php/* EAPI=6 packages, and reverse dependencies of them.
> # composer has active security vulnerabilities. Others are waiting
> # for version bumps, and unbundling of dependencies.
> # Removal on 2024-07-21.  Bugs #934666.
> dev-php/phpDocumentor
> dev-php/phpcov
> dev-php/phpdepend
> dev-php/phpdocumentor-reflection-common
> dev-php/phpdocumentor-reflection-docblock
> dev-php/phpdocumentor-type-resolver
> dev-php/stringparser_bbcode
> dev-php/symfony-config
> dev-php/symfony-console
> dev-php/symfony-dependency-injection
> dev-php/symfony-event-dispatcher
> dev-php/symfony-yaml
> dev-php/composer

[-- Attachment #2: Type: text/html, Size: 1930 bytes --]

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

[Michael Orlitzky]

On Wed, 2024-09-11 at 09:33 +0200, Jaco Kroon wrote:
> Hi,
> 
> I missed this announcement, looking specifically for composer again.
> 
> If I make the effort of bumping to newest version, is this something 
> that would be re-added to the tree?

I'd re-commit if you're interested in keeping up with it. It brings a
lot of dependencies with it though. It was initially added in

  https://github.com/gentoo/gentoo/pull/2905

(where you can see the deps) and I'll bet the list is even longer now.

Updating them is more annoying than usual because they all want
autoload.php files that aren't in the source tarball:

  https://wiki.gentoo.org/wiki/Composer_packaging

IIRC the "classmap" format is particularly annoying because you have to
regenerate it with every release.

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

[Jaco Kroon]

[-- Attachment #1: Type: text/plain, Size: 2977 bytes --]

Hi Michael,

Looks like we keep bumping into each other ... and not only on PHP packages.

n 2024/09/11 13:26, Michael Orlitzky wrote:
> On Wed, 2024-09-11 at 09:33 +0200, Jaco Kroon wrote:
>> Hi,
>>
>> I missed this announcement, looking specifically for composer again.
>>
>> If I make the effort of bumping to newest version, is this something
>> that would be re-added to the tree?
> I'd re-commit if you're interested in keeping up with it. It brings a
> lot of dependencies with it though. It was initially added in
>
>    https://github.com/gentoo/gentoo/pull/2905
>
> (where you can see the deps) and I'll bet the list is even longer now.
>
> Updating them is more annoying than usual because they all want
> autoload.php files that aren't in the source tarball:
>
>    https://wiki.gentoo.org/wiki/Composer_packaging
>
> IIRC the "classmap" format is particularly annoying because you have to
> regenerate it with every release.


Right.  What I take away from this is that PHP trying to incorporate 
things that annoy me about other languages is a pain in the backside.

All I really need (and I think this is in line with something you 
mentioned in one of our other discussions) is that PHP source files are 
typically no longer packaged, because everyone uses composer now to just 
pull in dependencies from just about anywhere, and often poorly vetted, 
outdated versions.

What I really just need is a way to for a specific PHP deployed app be 
able to run composer to pull in those dependencies into a normal user 
account so that I can properly isolate the specific PHP app.

I think it's useful to have the composer command available on Gentoo, 
but I do agree with the principle of letting each deployment manage it's 
own rather.

Ie, my *opinion* is that Gentoo should package the interpreters and any 
pecl-* stuff which is compiled.  And let the apps handle their own sources.

composer I reckon is a bit of a tricky one here because it looks like it 
itself is a source-based thing, and pulls in a bunch of it's own deps then?

Looking at what one of our clients did is they have a versioned 
composer.phar ... which means deps are packaged.

https://getcomposer.org/download/ has these lower down, so IMHO three 
options here:

1.  Let users (myself included) just download and use that.
2.  We package the phar file rather than the individual deps. Yes, this 
is cheating.  Like using embedded libs, however, I've seen and observed 
that in some cases this makes more sense than splitting them up (eg 
clippy and frr).
3.  We go about figuring everything out again and bumping all those 
individual packages and keeping them all up to date individually.  I 
don't think this is worth our time and effort.

I honestly think in this case 2 may well be acceptable. Otherwise 1, but 
I think 3 is not worth the effort based on your feedback and further 
reading from when I originally posed the question to now.

Your opinion?

Kind regards,
Jaco

[-- Attachment #2: Type: text/html, Size: 4677 bytes --]

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

[Michael Orlitzky]

On 2024-09-11 17:23:16, Jaco Kroon wrote:
> 1.  Let users (myself included) just download and use that.
> 2.  We package the phar file rather than the individual deps. Yes, this 
> is cheating.  Like using embedded libs, however, I've seen and observed 
> that in some cases this makes more sense than splitting them up (eg 
> clippy and frr).
> 3.  We go about figuring everything out again and bumping all those 
> individual packages and keeping them all up to date individually.  I 
> don't think this is worth our time and effort.
> 
> I honestly think in this case 2 may well be acceptable. Otherwise 1, but 
> I think 3 is not worth the effort based on your feedback and further 
> reading from when I originally posed the question to now.

I agree that (3) is probably too much trouble. It might be worth it if
someday people want to bring back other packages that would benefit
from the deps, like PHPUnit.

I don't like (2) because there's no way for the security team to know
what's inside composer.phar, and no way for users to tell that they've
got ~15 bundled dependencies in a tool that's extremely
sensitive. So... what I've been doing is putting composer.phar in
/usr/local/bin. (I also run it as a separate user because I don't
trust the code it's downloading but that has nothing to do with
Gentoo.)

Re: [gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

[Jaco Kroon]

Hi,

On 2024/09/13 12:22, Michael Orlitzky wrote:

> On 2024-09-11 17:23:16, Jaco Kroon wrote:
>> 1.  Let users (myself included) just download and use that.
>> 2.  We package the phar file rather than the individual deps. Yes, this
>> is cheating.  Like using embedded libs, however, I've seen and observed
>> that in some cases this makes more sense than splitting them up (eg
>> clippy and frr).
>> 3.  We go about figuring everything out again and bumping all those
>> individual packages and keeping them all up to date individually.  I
>> don't think this is worth our time and effort.
>>
>> I honestly think in this case 2 may well be acceptable. Otherwise 1, but
>> I think 3 is not worth the effort based on your feedback and further
>> reading from when I originally posed the question to now.
> I agree that (3) is probably too much trouble. It might be worth it if
> someday people want to bring back other packages that would benefit
> from the deps, like PHPUnit.
>
> I don't like (2) because there's no way for the security team to know
> what's inside composer.phar, and no way for users to tell that they've
> got ~15 bundled dependencies in a tool that's extremely
> sensitive. So... what I've been doing is putting composer.phar in
> /usr/local/bin. (I also run it as a separate user because I don't
> trust the code it's downloading but that has nothing to do with
> Gentoo.)
>
I think, then let's stick with that.

I'm not able to edit https://wiki.gentoo.org/wiki/Composer_packaging in 
order to make reference of this dicussion there so others looking at it 
will understand what the motivation is.  In the meantime I'm sorted at 
least.

Thanks for the constructive discussion.

Kind regards,
Jaco

[gentoo-dev] Re: Last rites EAPI=6 packages: dev-php/*

[Duncan]

Jaco Kroon posted on Wed, 11 Sep 2024 09:33:10 +0200 as excerpted:


> I missed this announcement, looking specifically for composer again.
> 
> If I make the effort of bumping to newest version, is this something
> that would be re-added to the tree?
> 
> I note there were active security vulnerabilities under very specific
> conditions (composer.phar is exposed via http).
> 
> Or should I rather just deploy this into a local overlay?

[Tree or local overlay?]

You seem to have missed the obvious middle option, deploying to a public 
overlay.

If there's many related packages (another reply mentioned a bunch of deps; 
not being a PHP person I wouldn't know...) that might most appropriately 
be a dedicated overlay.

For single packages, particularly if there's likely to be others 
interested, the guru overlay seems to be quite popular as a middle ground, 
allowing multiple people to help without the full bureaucracy of the main 
tree.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman