Customizing packages?
Hi there, I wonder how you long-time CRUXers handle the case if a package from core/opt/xorg/contrib port does not suit your needs? I read it is discouraged to create duplicate (local) packages but alternatives like installing local builds directly in /usr/local, /opt or ~/.local seem also suboptimal. For example, I need sftp support in libcurl which needs linking against libssh. This is not configured in the official port. So I have to create my own solution and I want it to integrate as smooth as possible with the ports systems and keep CRUX's philosophy. What do you recommend? Thanks for your input! Best regards, Martin
Hi. If the configure script don't pick up on extra features and libraries on its own, I would maintain my own version of the port in /usr/ports/mine or similar. Custom ports should be listed by ports -d when the installed version of the port is older than what can be find in core/opt/contrib. -- Joacim <hi@joac.im> On Mon, 2022-06-20 at 21:25 +0200, Martin Michel wrote:
Hi there,
I wonder how you long-time CRUXers handle the case if a package from core/opt/xorg/contrib port does not suit your needs?
I read it is discouraged to create duplicate (local) packages but alternatives like installing local builds directly in /usr/local, /opt or ~/.local seem also suboptimal.
For example, I need sftp support in libcurl which needs linking against libssh. This is not configured in the official port. So I have to create my own solution and I want it to integrate as smooth as possible with the ports systems and keep CRUX's philosophy. What do you recommend?
Thanks for your input!
Best regards, Martin _______________________________________________ CRUX mailing list CRUX@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Martin, for that purpose I maintain a git repository of patches, which are added/applied by the "ports" program. Then pkgmk and prt-get pick it up: https://git.eckner.net/Erich/crux-patches/ The patch for core/ports adds exactly this functionality, while the other three patched ports add functionality which I was missing. The idea is, that *.patch files are applied in the ports directory (e.g. a patch to the Pkgfile) and *.new files are simply added to the ports directory (e.g. new patches, that should be applied during the compilation). The system is not perfect, but for minor changes (e.g. adding an option in the Pkgfile) it's pretty straight forward. regards, Erich On Mon, 20 Jun 2022, Joacim wrote:
Hi.
If the configure script don't pick up on extra features and libraries on its own, I would maintain my own version of the port in /usr/ports/mine or similar. Custom ports should be listed by ports -d when the installed version of the port is older than what can be find in core/opt/contrib.
-- Joacim <hi@joac.im>
On Mon, 2022-06-20 at 21:25 +0200, Martin Michel wrote:
Hi there,
I wonder how you long-time CRUXers handle the case if a package from core/opt/xorg/contrib port does not suit your needs?
I read it is discouraged to create duplicate (local) packages but alternatives like installing local builds directly in /usr/local, /opt or ~/.local seem also suboptimal.
For example, I need sftp support in libcurl which needs linking against libssh. This is not configured in the official port. So I have to create my own solution and I want it to integrate as smooth as possible with the ports systems and keep CRUX's philosophy. What do you recommend?
Thanks for your input!
Best regards, Martin _______________________________________________ CRUX mailing list CRUX@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux
CRUX mailing list CRUX@lists.crux.nu https://lists.crux.nu/mailman/listinfo/crux
-----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmKxUUsACgkQCu7JB1Xa e1pthQ/7BQYyPrVASEmXIXLNTcm5EcYlqDchL4UbpzQb5aXSREsOpqoYKAo67k1u wum0ywDcEnW2g5W6aRFQ1AxoeP5aEh3+3ldOMouGdP1uF0UQyvx2Z9Z7Yd2jSges uRstCyNVWQ6vRUHifUC62ujsUbQGbbh/1OIPVvI46MEfSlUYYu1BD3IkbxtExRh2 AneXIHALxA8J5FrosVidq+hg2+2R+aCrE/xCeH4ptj3PNpYkDW+HM4fRo4vEo7Wx ERHayZOHc3O6VjNiT+q2wDiZys80PvjcYsq/qQecUh3j6T5tDDKEOwPFH3XZDaTg 0d/PGQi7BE+oZLzY+2mHI83W+v6KwRIytWKbHdwg6v44jrXHi9cXUBRiPFZ/gbjc eMGBJiXSILSMLWS7Vh1TS+sUbYFzDhrrUYK6MqnP+1JtIEyEH6X4EfOaeZ455xSl 3DMFpaxo94gl9jiSfieP+TaXVPxkVNgHr2xr+Rjzz6V8+MMgmYY3eFqC/1XbSAPU z3yV3I1Vq4N0n/9fq98H30EiP8GmeI3lSpsuQKS+TQA8lYRC6AfRLyok7bz5GOew ByxcvJ3XRPlG+X+B9aX795/soz7bnOFb59353jBdtbAx8Z6JkvrYDgG8htxqBX4P VVCEwrhSuA4fqW3D0TYRmaFhlJsTrH6xkhuZTyOvemcATJLN+Ns= =XNQw -----END PGP SIGNATURE-----
Erich, thanks for sharing this! It is a great idea, I like the concept. I see some advantages to the alternative, i.e. keeping personal, local ports. Mainly I do not have to keep/track two ports of the same package, that's nice.
The system is not perfect, but for minor changes (e.g. adding an option in the Pkgfile) it's pretty straight forward.
Of course nothing is perfect, but where do you see the main drawbacks or what are you practical limitations? —Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Martin, On Wed, 22 Jun 2022, Martin Michel wrote:
Erich,
thanks for sharing this! It is a great idea, I like the concept.
I see some advantages to the alternative, i.e. keeping personal, local ports. Mainly I do not have to keep/track two ports of the same package, that's nice.
The system is not perfect, but for minor changes (e.g. adding an option in the Pkgfile) it's pretty straight forward.
Of course nothing is perfect, but where do you see the main drawbacks or what are you practical limitations?
The main drawbacks are: * Sometimes, you need to adapt patches, because unrelated, but adjacent lines in the Pkgbuild changed. * It seems to be against the KISS principle to add a layer of patches. * You need to re-sign all packages which you changed. Thus, you need your own ports signing key, and if the script makes some error when checking the signature, you loose the signature integrity check completely (the changed package will be re-signed, thus trusted by pkgmk). This is sub-optimal from an academic point of view. * Updating ports incrementally will not work for patched ports: `ports -u` will update them to the unpatched version and then patch them again. Depending on how many ports you intend to change and how often you do `ports -u`, this might become an issue. * There's no documented way to bootstrap. And you will need to bootstrap each time, you replace the `ports` package by a pre-compiled one (e.g. by doing a verion update of crux itself).
—Martin
regards, Erich -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAmKzeXYACgkQCu7JB1Xa e1rWPBAAh9dvWacqsPeKDwgddRrxhi2JbgCKgS7A6akM1bb/84i1bhrygfZB6d/4 Q+dui9vvTKbzH5ETp86wLqn4YkBLi5uM0bW3a2KGgzaGevi6Pu0YmwHrnRu7Woti lCb2Fjv5nSNiEKx/Tx4/B6QSds0+u3fg4WSWgsrDRmRIAuNCt/c2QtHUXRMYXupI fpA3fud8khxnbXHfZYmGSfcDKjuRKbDw/oyrGMeV8DMU8IdljT6gJI08LQzmr+uq Xqt2F4e1jMsZUrn7+Xt5+7UEMPKXNtniEaOs5o8tuBxFLXYXjDnJMjgIvf24dEhd 2VIm67TfoeSP1WTc8BSzgQxwuEQo8Zx4hezIgj9dXUWVrMJMMmERKv0Uuov88WaT WHeTnngkfOjy/wZmaKVzU7sAwvmapPBZjFdTCS7ebm9Hzc/070wZnEMCqYpL29pQ lM93hHYsRpfpiufrWbOpNPNNNMtMBYAp0VTb1jSxHvdES3RaYcCS4Nqh18POj5m2 Uc2irpB8bXSHOH25qBue1deuDuYP+L6rq2SD97lChRb0c1sM1Hc8YArGNVcrvfD7 Ji774ZwhgToHmgOVOKS6o6i7ppOzHBzljXGCKpnJ2UWKCO0YktHyb3n7dtFFJg1Z F/3YbntjgEsHNOEtgFg5tHlwd57x6TG7g0EtpdlWI1kPvizd1ng= =xeIu -----END PGP SIGNATURE-----
On 2022-06-20 14:25, Martin Michel wrote:
Hi there,
I wonder how you long-time CRUXers handle the case if a package from core/opt/xorg/contrib port does not suit your needs?
I read it is discouraged to create duplicate (local) packages but
[...] Greetings! You mentioned you've read this is discouraged but personally, I always use this method in the interest of keeping it simple. It's your system, so feel free to do it however you like. Regards, Matt
Joacim, Matt, if I understood correctly, you recommend to keep the customized packages in "personal", local ports. Basically in parallel to the official ports. Should I then rank this personal port directory higher than core/opt in prt-get.conf? Because I want to avoid that the customized package gets overwritten by a `prt-get sysup`. I tried this once but quickly ran into an error message at the next system update, something like "Cyclic dependencies". However, I can't reproduce it right now. So is there anything special to consider for configuration of such a setup? Best regards, Martin
On 2022-06-22 14:35, Martin Michel wrote:
Joacim, Matt,
if I understood correctly, you recommend to keep the customized packages in "personal", local ports. Basically in parallel to the official ports.
Should I then rank this personal port directory higher than core/opt in prt-get.conf? Because I want to avoid that the customized package gets overwritten by a `prt-get sysup`. I tried this once but quickly ran into an error message at the next system update, something like "Cyclic dependencies". However, I can't reproduce it right now.
So is there anything special to consider for configuration of such a setup?
Yes, this is what I would suggest and what I do as well. Nothing really special to consider, in my opinion, you're already aware of prt-get's priority list. Cheers, Matt
participants (4)
-
Erich Eckner
-
Joacim
-
Martin Michel
-
Matt Housh