<div dir="ltr"><div>> somewhere here I stop to understand why we need the fork to keep it?<br>> To avoid tickets in track?</div><div><br></div><div>It can be set in the policy not to file Trac tickets for < 10.x, or priority can be set to low automatically.</div><div><br></div><div>Having a separate repo is gonna be an unmaintainable disaster IMO indeed.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 8, 2024 at 11:29 PM Kirill A. Korinsky <<a href="mailto:kirill@korins.ky">kirill@korins.ky</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="line-break:after-white-space"><div><blockquote type="cite"><div>On 8. Jan 2024, at 16:18, Perry E. Metzger <<a href="mailto:perry@piermont.com" target="_blank">perry@piermont.com</a>> wrote:</div><br><div>

  
    
  
  <div>
    <div>On 1/8/24 10:12, Kirill A. Korinsky
      wrote:<br>
    </div>
    <blockquote type="cite">
      <blockquote type="cite"><span></span><span>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>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>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>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>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>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><br></div><div>and the way with fork soon will be adding to the end of each affected Portfile something like that:</div><div><br></div><div></div><blockquote type="cite"><div>if (condition for old system) {</div><div>some hacks here</div><div>}</div></blockquote><div><br></div><div>somewhere here I stop to understand why we need the fork to keep it?</div><div><br></div><div>To avoid tickets in track?</div><br><div>
-- <br>wbr, Kirill
</div>
<br></div></blockquote></div>