Creating custom ports versions.
steffen at sdaoden.eu
Wed Nov 27 21:43:01 UTC 2019
Erich Eckner wrote in <alpine.LNX.2.21.99999.378.1911270624480.7142 at desk\
|On Tue, 26 Nov 2019, Steffen Nurpmeso wrote:
|> Erich Eckner wrote in <alpine.LNX.2.21.99999.375.1911250848400.2310480 at n\
|>|On Mon, 25 Nov 2019, KPECT wrote:
|>|> Very often I use slightly modified ports just to achieve some additiona\
|>|> l \
|>|> remove some extra options that the original port provides. I'd like to
|>|> suggest to propose implementing a new ports function that would allow \
|>|> 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
|>|> 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 \
|>|The feature itself is implemented as a patch to 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 \
|>|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
|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
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.
|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)
More information about the CRUX