Erich Eckner wrote in <alpine.LNX.2.21.99999.375.1911250848400.2310480@n\ lopc43.ioq.uni-jena.de>: |On Mon, 25 Nov 2019, KPECT wrote: |> Very often I use slightly modified ports just to achieve some additional \ |> or |> remove some extra options that the original port provides. I'd like to |> suggest to propose implementing a new ports function that would allow \ |> users |> to create a child port (for example in /usr/ports/custom) that has \ |> the same |> name as the parent, but which has some differences that the user needs. |> Every time the ports are updated if the version of the parent port is |> changed, this also affects the child ports, so you do not need to \ |> track them |> manually. .. |> I belieive that this is very demanded function. .. |I would definitely use that feature. My approach so far was: I also think this would be a nice feature! I could use that for the minimum adjustment i need for dnssmasq, for example. |put patches into /usr/patches/$repository/$port/ | |and apply them during `ports -u`, resigning the ports using a private key. | |The feature itself is implemented as a patch to ports: | |https://git.eckner.net/Erich/crux-patches/tree/core/ports | |What I like about this approach (and what I would like to see in an |official implementation, too), is, that you do not need to modify anything |in order to keep your packages up-to-date - as long as your patches |still cleanly apply. That is true. What i do not like with your approach is that the original port is lost. I mean, one could reverse-apply the patch and then everything is clear, even easier it is with a git-based port. But wouldn't it be nicer to have some e.g. PKGMK_PATCH_DIR= in /etc/pkgmk.conf, and to have build_package() of pkgmk look whether that exists and has something to apply for the current port, right after the call to unpack_source(), before it goes build()? On the other hand your approach integrates a signature. .footprint changes are a problem whatever you do?!? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Erich Eckner wrote in <alpine.LNX.2.21.99999.378.1911270624480.7142@desk\ .ddns.eckner.net>: |On Tue, 26 Nov 2019, Steffen Nurpmeso wrote: |> Erich Eckner wrote in <alpine.LNX.2.21.99999.375.1911250848400.2310480@n\ |> lopc43.ioq.uni-jena.de>: |>|On Mon, 25 Nov 2019, KPECT wrote: |>|> Very often I use slightly modified ports just to achieve some additiona\ |>|> l \ |>|> or |>|> remove some extra options that the original port provides. I'd like to |>|> suggest to propose implementing a new ports function that would allow \ |>|> users |>|> to create a child port (for example in /usr/ports/custom) that has \ |>|> the same |>|> name as the parent, but which has some differences that the user needs. |>|> Every time the ports are updated if the version of the parent port is |>|> changed, this also affects the child ports, so you do not need to \ |>|> track them |>|> manually. |> .. |>|> I belieive that this is very demanded function. |> .. |>|I would definitely use that feature. My approach so far was: |> |> I also think this would be a nice feature! I could use that for |> the minimum adjustment i need for dnssmasq, for example. |> |>|put patches into /usr/patches/$repository/$port/ |>| |>|and apply them during `ports -u`, resigning the ports using a private \ |>|key. |>| |>|The feature itself is implemented as a patch to ports: |>| |>|https://git.eckner.net/Erich/crux-patches/tree/core/ports |>| |>|What I like about this approach (and what I would like to see in an |>|official implementation, too), is, that you do not need to modify \ |>|anything |>|in order to keep your packages up-to-date - as long as your patches |>|still cleanly apply. |> |> That is true. What i do not like with your approach is that the |> original port is lost. I mean, one could reverse-apply the patch |> and then everything is clear, even easier it is with a git-based |> port. But wouldn't it be nicer to have some e.g. PKGMK_PATCH_DIR= |> in /etc/pkgmk.conf, and to have build_package() of pkgmk look |> whether that exists and has something to apply for the current |> port, right after the call to unpack_source(), before it goes |> build()? | |One could improve this approach by saving the (modified) ports somewhere |else, so the original one is still available. This couls also be done |during `ports -u`. I tried not to change pkgmk, so I can still blame |errors during compilation on the source instead of having to make sure it |is not due to my hackery. Any download related thing is definetely better preserved where you placed it. |> On the other hand your approach integrates a signature. |> .footprint changes are a problem whatever you do?!? | |Just add a .footprint.patch and you're done (though I don't use this in my |/usr/patches tree). Sure. All in all CRUX is maybe not prepared that well for such a patch system. For example, my dnsmasq-nodnssec port only changes dependencies and the make invocation. Others, gentoo for example, split configuration and building, which would make such simple edits much easier. With CRUX you could only overwrite build() as a whole, or provide NAME_hook() functions to apply edits. And this does not affect dependency resolving that is entirely unrelated to pkgmk. So your ports patch system is possibly the best as it umbrellas over all the other utilities below it. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)