Opened 12 years ago

Closed 11 years ago

#19336 closed enhancement (fixed)

php5/swig: Remove apache2 from the default installation

Reported by: raimue (Rainer Müller) Owned by: kevin@…
Priority: Normal Milestone:
Component: ports Version: 1.7.1
Keywords: default_variants apache2 Cc: ryandesign (Ryan Schmidt), jyrkiwahlstedt, jameskyle@…, skymoo (Adam Mercer), jmroot (Joshua Root)
Port: php5 swig

Description

php5 has +apache2 in the default_variants, which add a dependency on apache2. This means, anyone who installs php5 is required to installed apache2 as well.

The swig port offers language bindings for several ports using variants, including php5. It has +php5 in the default_variants.

So, installing swig also installs apache2 by default. This is not very nice to the user as apache2 is not lightweight. Also, this can happen if the user actually needs swig for e.g. python bindings.

Can we please either remove the default +apache2 from php5 or the default +php5 from swig?

Change History (11)

comment:1 Changed 12 years ago by raimue (Rainer Müller)

Summary: php5: Remove +apache2 from default_variantsphp5/swig: Remove apache2 from the default installation

comment:2 Changed 12 years ago by jameskyle@…

Cc: jameskyle@… added

Cc Me!

comment:3 Changed 12 years ago by alakazam@…

Actually as some (at least graphviz +php, haven't search further) ports probably depend on swig having the +php5 variant active, I think removing the default +php5 may not be an option (as we can't depend on specific variants yet). Maybe the same problem is present for the default +apache2 variant ?

comment:4 Changed 12 years ago by ryandesign (Ryan Schmidt)

php used to be a language used only for web sites. The php ports used to build with support for Mac OS X Apache by default if you did not specify otherwise. This caused default installs of php to fail on Leopard (as reported in #16478) because Leopard includes Apache 2 instead of Apache 1. I changed it in r39862 so that +apache2 was the default on all systems, both to fix the Leopard issue and to promote the use of MacPorts software instead of Apple software, as is our standing policy. I also made it possible to build with no web server support using a new +no_web variant. However this is not the default because we have many ports in MacPorts for web apps which declare a dependency on php5. If php5 did not install web support by default, those web apps would not be usable.

swig, in its own right, declares dependencies on as many languages as possible by default, since ports that declare dependencies on swig assume swig can generate any requested language binding.

I would like to fix this for php by breaking php into many ports. There will be separate ports for each SAPI, so that if you just require some basic form of PHP to be present, you can declare a dependency on, say, php5-core; if you require php with web support, you can declare a dependency on, say, php5-web; and if you require specifically apache2 support in php, you could declare a dependency on php5-apache2. See #19091 for details of this task.

comment:5 Changed 12 years ago by (none)

Milestone: Port Enhancements

Milestone Port Enhancements deleted

comment:6 Changed 12 years ago by skymoo (Adam Mercer)

Cc: ram@… added

You can have a check that a given variant of swig is installed with something like the following:

pre-fetch {
  if {![llength [glob -nocomplain ${prefix}/share/swig/*/python/python.swg]]} {
    ui_error "The python variant of swig is not installed. Please run"
    ui_error "the following commands:"
    ui_error "$ sudo port uninstall swig"
    ui_error "$ sudo port install swig +python"
    error "python variant of swig required"
  }
}

I have this the py25-scipy port to check that python variant of swig is installed, something similar could be added for ports that require the php variant thereby making swig much lighter.

comment:7 Changed 12 years ago by Chris.Barker@…

I just installed swig, as I need it for some python binding work ,and was surprised and dismayed about how much stuff it brought in!

I ended up doing -php5, etc , but I wonder:

Is it really required to install perl, php, python, etc in order to build and install swig? Clearly itn's required to have, for example, php if you actually want to build swig bindings for php, but I don't think you need the target language installed in order to build swig, and I don't think you even need to run swig to generate bindings -- you only need it when you want to compile those bindings.

If I'm right about that, I'd suggest removing all those dependencies. Anyone that wants to build bindings for a given language would be pretty likely to install that language directly.

I guess this come down to philosophy: the current set up follows the "when in doubt, include it" approach, but I know I'd rather a more minimalist -- "only include if you really need it" approach.

comment:8 Changed 12 years ago by jameskyle@…

This ticket has been stagnating for a while, but I feel pretty strongly that php5 should be removed as a default variant until swig is split up or apache2 is removed from the default variants of php5. I'll walk through my reasoning for this, interim solutions, and address some concerns in this ticket.

I think removing the default +php5 may not be an option (as we can't depend on specific variants yet).

I've taken to using the above variant check for all my python swig dependent ports. I would suggest that people depending on php5 + swig could do the same. Defaulting to a "everything and the kitchen sink" policy is not a direction we should be moving in. Further, the upgrade process does not yet respect removed variants. For example, installing swig with -php5 on a subsequent port upgrade outdated, it will happily install php5 and an entire web stack while your not looking. The converse is not true, if users had to specify +php5 this would be respected.

One method asserts a minor inconvenience up front, but respects that choice throughout upgrade cycles. The other requires constant vigilance on the part of the user.

However this is not the default because we have many ports in MacPorts for web apps which declare a dependency on php5. If php5 did not install web support by default, those web apps would not be usable.

I think the variant checks could solve this issue for those apps. I realize this puts an extra burden on maintainers, but the opposite policy puts a significant burden on the non-web admin/developer macports user. It makes sense that whenever possible, we should shift such technicalities onto the maintainers rather than the users who may not even be aware of the issue prior to installing.

swig, in its own right, declares dependencies on as many languages as possible by default, since ports that declare dependencies on swig assume swig can generate any requested language binding.

This is not completely true, of the possible 17 variants only 4 are default. Given they're likely the most common 4 languages and I have nothing against php5. However, it's the fact that by default php5 brings in a wicked dependency tree that's gaining it this attention. I don't think there'd be near the issue if the php5 variant only installed php5.

I think what this boils down to is that a package manager shouldn't make wild presumptions as to the user's intentions. I would call the presumption that a user wants to run a full web stack based on their indirect installation of swig falls into the "wild speculation" category. Assuming that a user may want to create bindings between the X most popular languages when they install swig does not.

For that reason, until either apache2 is removed from php5, swig is rewritten to bust up the language dependencies, or macports incorporates better variant dependency support php5 should be removed from the default swig variant list.

comment:9 Changed 11 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added; kevin@… removed
Owner: changed from ryandesign@… to kevin@…

php5 will remove the apache2 dependency as soon as apache module support is in a separate php5-apache port, which is handled in #19091. There's also now a php5-web port which webapp ports are meant to depend on instead of depending on php5 directly.

That leaves this ticket for the maintainer of swig to decide whether he wants to change its default variants.

comment:10 Changed 11 years ago by ryandesign (Ryan Schmidt)

Cc: jmr@… added

Joshua split swig into separate ports for each binding in r60005 and r60006. That should help with this issue.

comment:11 Changed 11 years ago by jmroot (Joshua Root)

Resolution: fixed
Status: newclosed

This is pretty clearly fixed.

Note: See TracTickets for help on using tickets.