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
