On 12 Aug 2007, at 07:25, [EMAIL PROTECTED] wrote:
Ryan Schmidt <[EMAIL PROTECTED]> 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!)
-Markus
---
Markus W. Weissmann
http://www.mweissmann.de/
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
