Sun, 12 Aug 2007 (00:02 -0500 UTC) Ryan Schmidt wrote:

I'm not sure I like that mtree violations are fatal errors. The ports that are now failing to install because of mtree violations installed just fine in MacPorts 1.5.0. Why should they now fail to install? Their content has not changed. Sure, they may be installing things in places they shouldn't, but why should we make the user suffer? We have a -t switch which informs us about forgotten dependencies in the port -- but this does not issue a fatal error. It's just a message which portfile authors can use to improve their portfiles. Maybe mtree violations could be handled similarly.

I'm also concerned about needing to specify in the portfile that the port intends to violate the mtree. For example, I'm going to have to add that to the php5 port, because it wants to install an apache2 module and the apache2 layout is considered nonstandard. So just because I want to install one item in a weird place, I have to turn off the mtree violation checks in the entire php5 portfile. It would be nicer if port would just issue nonfatal debug messages letting us know exactly which files were violating the mtree. This way I could assure myself that my port is installing the apache2 module in a weird place, yes, but that everything else is being installed in sane locations.

What if you were to add a directive for port file such as add_to_mtree_exceptions(portname|portgroup, [exception-paths, ...]) Then each exceptional port could be registered when it installs. The database could be seeded with ports in certain groups such as aqua. When a port lists a dependency on one of the exceptionals, and that port tries to install something outside ${prefix}, the install path could be checked against the exceptions stored for the dependency and any new ones added by the port. If the directory is not in the list, then a warning gets issued. -- Dr. Robert Delius Royar Associate Professor of English Morehead State University Morehead, Kentucky

Weissmann Markus wrote:

we've documented the should-be state of the layout of the ports-filesystems years ago already - see porthier(7); if ports fail because of this right now, it is most likely either because our implementation is faulty or the port is buggy.

Seems like "src" is missing from the porthier/mtree, this breaks the "port rpm/srpm" targets and the "rpm/rpm-devel" ports. I'd prefer if it could be added to the hier, rather than having to make /opt/local/src/macports an exception from the rules ? --anders

On 12 Aug 2007, at 22:14, Weissmann Markus wrote:

On 12 Aug 2007, at 07:25, markd@macports.org wrote:

...

Ryan Schmidt <ryandesign@macports.org> writes:

...

I'm not sure I like that mtree violations are fatal errors. The ports that are now failing to install because of mtree violations installed just fine in MacPorts 1.5.0. Why should they now fail to install? Their content has not changed. Sure, they may be installing things in places they shouldn't, but why should we make the user suffer? We have a -t switch which informs us about forgotten dependencies in the port -- but this does not issue a fatal error. It's just a message which portfile authors can use to improve their portfiles. Maybe mtree violations could be handled similarly.

I'm also concerned about needing to specify in the portfile that the port intends to violate the mtree. For example, I'm going to have to add that to the php5 port, because it wants to install an apache2 module and the apache2 layout is considered nonstandard. So just because I want to install one item in a weird place, I have to turn off the mtree violation checks in the entire php5 portfile. It would be nicer if port would just issue nonfatal debug messages letting us know exactly which files were violating the mtree. This way I could assure myself that my port is installing the apache2 module in a weird place, yes, but that everything else is being installed in sane locations.

+1 And I still don't know exactly what an mtree violation is.

we've documented the should-be state of the layout of the ports- filesystems years ago already - see porthier(7); if ports fail because of this right now, it is most likely either because our implementation is faulty or the port is buggy.

The deal is, that port(1) should really protect a user from having files installed "somewhere", e.g. in /System; if a port really has to install files in a non-standard location, it should indicate this. Installing files e.g. in /usr can be fatal for a system and can render it unusable. A port might overwrite system files, install some kernel extension, etc. I do not see a reason to not protect a user from an accident like this. (The trace mode will not protect you here, it keeps ports from writing to wrong locations before the install phase.)

For the rare occasion that it is necessary to install e.g. a kext, an indication by the port author is not a big deal. I assume that only a few ports require this right now while we might find some dozen ports which are just buggy and no one noticed so far.

There is a bug in the current implementation that incorrectly complains about files in e.g. "/Applications" which has been fixed in trunk already. (but is in 1.5.1!)

Just before this one gets a stopper for a lot of ports: Juan will look into doing a 1.5.2 (or whatever) release which includes the fix for the "/Applications" bug and also turns the violation errors into non-fatal warnings (for now). I should have done it this way from the start, to let us do some cleaning before the fist of quality assurance hits our ports. If someone comes up with a better name for 'mtree violation' please let me know - obviously it is not very self-explanatory... -Markus --- Markus W. Weissmann http://www.mweissmann.de/