> On 8. Jan 2024, at 16:08, Perry E. Metzger <[email protected]> wrote: > > On 1/8/24 09:53, Kirill A. Korinsky wrote: >>> On 8. Jan 2024, at 15:50, Perry E. Metzger <[email protected]> wrote: >>> >>> I'd like to float the idea that we create a fork of the MacPorts repository >>> that is devoted to operating systems and hardware that is more than (say) a >>> decade old, and that we allow the people who are interested in maintaining >>> that software to freely work on it. It doesn't hurt the rest of us after >>> all, and it absolves us of the need to keep the main MacPorts repository >>> complicated by patches to support very old systems. >>> >>> >>> How do you see the way to backport changes from upstream MacPorts to legacy >>> MacPorts? >>> >>> at some point automatical merge would be broken on conflicts, and I assume >>> quite fast. > > 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. -- wbr, Kirill
signature.asc
Description: Message signed with OpenPGP
