> somewhere here I stop to understand why we need the fork to keep it? > To avoid tickets in track?
It can be set in the policy not to file Trac tickets for < 10.x, or priority can be set to low automatically. Having a separate repo is gonna be an unmaintainable disaster IMO indeed. On Mon, Jan 8, 2024 at 11:29 PM Kirill A. Korinsky <[email protected]> wrote: > On 8. Jan 2024, at 16:18, Perry E. Metzger <[email protected]> wrote: > > On 1/8/24 10:12, Kirill A. Korinsky wrote: > > 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. > > 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. > > 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. > > 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. > > 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. > > If by overlay you mean a dedicated repository which overlays existed > Portfile for some port, it will be desister to maintain, isn't it? > > and the way with fork soon will be adding to the end of each affected > Portfile something like that: > > if (condition for old system) { > some hacks here > } > > > somewhere here I stop to understand why we need the fork to keep it? > > To avoid tickets in track? > > -- > wbr, Kirill > >
