<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On 8. Jan 2024, at 16:18, Perry E. Metzger <<a href="mailto:perry@piermont.com" class="">perry@piermont.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div class="">
<div class="moz-cite-prefix">On 1/8/24 10:12, Kirill A. Korinsky
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:FFBD241A-565E-48F2-BF20-A0B8A6B592AD@korins.ky" class="">
<blockquote type="cite" class=""><span style="white-space: pre-wrap" class=""></span><span style="white-space: pre-wrap" class="">I don't think there should be overly much in the way of trouble if legacy reasonably disciplined about frequently applying commits from upstream to legacy. If it's done often, then one doesn't risk falling far behind and having a giant mess to clean up. Someone would probably want to write something to semi-automate it based on a CI for legacy systems. Such work would be beyond the scope of the main project of course, but it would also make life easier for the people interested in legacy. It might even be possible to create some override mechanisms to parse in / "#include" a "legacy" portfile in with the upstream maintained portfile to reduce file diffs in legacy.</span></blockquote>
<pre wrap="" class="moz-quote-pre">Keep in mind that some new commits often broke old OS as well.
For example upgrade Rust which can be seen like a disaster for old systems.
</pre>
</blockquote><p class="">So I think that the solution there is (again) that legacy is
disciplined about not pulling in stuff that breaks it. David
Gilman is right that a social problem isn't always best solved
with technology, but I think in the present case, we have a great
deal of flexibility thanks to technology.</p><p class="">The Portfile format is, ingeniously, a tcl script. By adding a
small amount of fixes like allowing overlaying the main Portfile
with a legacy Portfile etc., it may be possible to make the whole
thing work quite cleanly without bothering "upstream" overly much.</p><p class="">It's unclear to me whether a repository consisting of "overlays"
or a fork that pulls from upstream is the better mechanism, but
that's a technical detail that can be hashed out.</p></div></div></blockquote></div><div class="">If by overlay you mean a dedicated repository which overlays existed Portfile for some port, it will be desister to maintain, isn't it?</div><div class=""><br class=""></div><div class="">and the way with fork soon will be adding to the end of each affected Portfile something like that:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">if (condition for old system) {</div><div class="">some hacks here</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">somewhere here I stop to understand why we need the fork to keep it?</div><div class=""><br class=""></div><div class="">To avoid tickets in track?</div><br class=""><div class="">
<meta charset="UTF-8" class="">-- <br class="">wbr, Kirill
</div>
<br class=""></body></html>