Support for ancient machines and operating systems

[Sergey Fedorov]

> 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 <kirill at korins.ky> wrote:

> On 8. Jan 2024, at 16:18, Perry E. Metzger <perry at piermont.com> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20240108/c4233356/attachment.htm>