mtree violations should be debug info, should not be fatal errors

[Weissmann Markus]

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

> On 12 Aug 2007, at 07:25, markd at macports.org wrote:
>
>> Ryan Schmidt <ryandesign at 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/