GSoC 2019 [Phase out dependency on Xcode]

[Mojca Miklavec]

Dear Satryaji,

On Mon, 1 Apr 2019 at 21:29, Satryaji Aulia wrote:
>
> Hi again Mojca and Marcus.
>
> >> I notice how useful a "port bump" command would be if it existed.
> >
> > Yes, it would be.
>
> I've started my implementation, under macports-base/src/port1.0/portbump.tcl.

Cool!

> Besides that, any feedback about my implementation would be appreciated. I currently use Tcl’s
> reinplace method to update the Portfile [2].

Even if that's still work in progress, may I suggest you to open a
pull request against macports base? If the code is not yet ready, mark
it as such, but it will be easier to provide feedback line-by-line,
and faster to merge it.

> > 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)
>
> I see. Then the php5 and ruby problems I encountered fall into the exception then, right?

Yes, we currently provide multiple versions for both php and ruby.
As far as php is concerned: yes, we do ship old unsupported versions,
but we also ship the latest one(s). Try "port info php".

Ruby on the other hand is a total mess. While we do ship the latest
version(s) of ruby, the packages for ruby are probably so outdated
that they are literally useless.

> It seems
> that these types of cases are not urgent, so I've discarded the sub-project idea of updating
> retired ruby/php5 ports.

Ruby is still an issue, whether or not that's urgent is a matter of
taste. Die-hard rubyist would probably turn to the other package
manager :). We are currently also not packaging asciidoctor, for
example (which would be nice to have for our documentation / guide).

> Also added the fact that there's already a proposal for that problem area.

Project may complement each other, and students are welcome to help
each other, in particular if one is stronger in a particular field. If
you are an eager rubyist, even if the upt project gets selected and
the ruby import gets implemented, the expertise and/or passion to
improve this area would still help.

Mojca