GSoC 2019 [Phase out dependency on Xcode]

[Mojca Miklavec]

Dear Satryaji,

On Sun, 31 Mar 2019 at 21:37, Satryaji Aulia wrote:
>
> - Xcode detection
>
> The detailed explanation is helpful and it clarifies a lot. So to me it seems like the core solution of the problem is simple but the extended functionality (trace mode) is a bit more complex. I'll research more about trace mode and get back ASAP. If it seems difficult, I'll put Xcode detection for stretch goals and assign my schedule with more doable tasks. Would you advise doing that, or do you think it's mandatory for this project idea?

I'm not in position to answer this, but you may check some discussion
on this mailing list (from March / GSOC) regarding trace mode, in case
it's relevant or provides you some more insight.

> - The "port bump" tool
>
> I did `port livecheck maintainer:nomaintainer` for several minutes and updated some Ports [1][2], one which I have used before (chromedriver) [3].

Thank you very much.

> I notice how useful a "port bump" command would be if it existed.

Yes, it would be.

> I will work on this feature right now. Hopefully I can make a functioning tool by the end of the week. I will add the extended implementation to my proposal.

Please also read the discussion (and code etc.) on this mailing list
related to "upt" as that's quite a bit related (not the same though).

> - Ports which depend on obsolete Ports

If a port depends on an obsolete port, it makes sense to figure out if
we can make it depend on the latest version (of that particular
dependency).

> A Port that need updating [4] depend on php5-web, but still depends on php5 (obsolete, successed by php53). The non-destructive solution would be to replace php5-web with a new app called php53-web I guess.
>
> Also, the ruby port is Ruby 1.8.7, which has been long retired since 2013 and all rb-* gems depend on it.
>
> It seems that people still use this version and some of the gems could be updated [5].
> What's the stance about supporting retired versions?

For most of the software we just ship one single version, the latest
one. Of course there are exceptions, usually in cases when:
- sufficient backward incompatibility is of concern (ruby on rails is
an excellent example; not that we have any support worth mentioning
for that one)
- dependent software is not yet compatible with the latest version
- the latest version doesn't work on older systems (and we care enough
to support the old systems)

We have no general guidelines, it's often up to maintainer, often not
exactly clear, and often we have different opinions. Some developers
are in favour of dropping support for python 3.6 packages, others
would keep ancient software that's no longer maintained. Generally we
are way more relaxed that the other package manager which threw away
tons of packages. On one way that's positive as you might be able to
get software that's not even possible to download upstream any longer,
on the other hand that means that we still provide a large number of
broken ports with zero maintenance, possibly scaring away users who
give up with macports after being scared off with unsuccessful attempt
to install such a package.

I have absolutely no idea about PHP, but our ruby support is
close-to-useless. The (latest) ruby port itself is probably OK, but
all other packages would need a lot of loving care from a volunteer.

If you read the mailing list, there's one proposal to somewhat help
automate importing ruby packages into MacPorts, but after the software
is written, there's still quite some work to actually prepare packages
that matter and test them. Any improvement of ruby situation would be
warmly welcome.

Mojca