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.
Perry
