On Dec 16, 2007, at 10:54, Simon Ruderich wrote:

I updated the ntfs-3g and added destroot.violate_mtree yes because it installs a file into /sbin (which is necessary).

Now a user reported to me he gets the following warning during install:

---> Fetching ntfs-3g ---> Verifying checksum(s) for ntfs-3g ---> Extracting ntfs-3g ---> Configuring ntfs-3g ---> Building ntfs-3g with target all ---> Staging ntfs-3g into destroot Warning: ntfs-3g requests to install files outside the common directory structure! ---> Installing ntfs-3g 1.1120_0 ---> Activating ntfs-3g 1.1120_0 ---> Cleaning ntfs-3g

Is this okay or did I miss anything?

This is normal. The port does request to install files outside of the common directory structure. That's what you've indicated by adding "destroot.violate_mtree" to the portfile. port is simply informing the user of this, because otherwise the user might rightly assume that all items were installed in "normal" places within ${prefix}.

On Dec 17, 2007, at 5:47 PM, Simon Ruderich wrote:

On Mon, Dec 17, 2007 at 04:22:48AM -0600, Ryan Schmidt wrote:

...

This is normal. The port does request to install files outside of the common directory structure. That's what you've indicated by adding "destroot.violate_mtree" to the portfile. port is simply informing the user of this, because otherwise the user might rightly assume that all items were installed in "normal" places within ${prefix}.

Hi Ryan,

thanks for your help. I added a small description to the guide. Is this okay? http://trac.macports.org/projects/macports/changeset/32129

"This is not really a warning" (quote from the Changeset) Well, actually it is. This indicates that the software that will just be installed does not meet our 'mtree' requirements *). Think of it more like a warning of a C compiler, like "warning: possible loss of precision" -- might be o.k. for you, but might also be fatal. Ports that e.g. have to install executables in /usr/sbin *) can totally hose your system. They probably won't, but they could. Perhaps we should make those fatal again and add an option to port(1) for ignoring warnings, like `port --I-know-what-Im-doing install foo'. Regards, -Markus *) for whatever reason PS: You have a duplicate "set" in the 1st sentence. -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/

On Mon, Dec 17, 2007 at 08:05:40PM +0100, Markus Weissmann wrote:

"This is not really a warning" (quote from the Changeset)

Well, actually it is. This indicates that the software that will just be installed does not meet our 'mtree' requirements *). Think of it more like a warning of a C compiler, like "warning: possible loss of precision" -- might be o.k. for you, but might also be fatal. Ports that e.g. have to install executables in /usr/sbin *) can totally hose your system. They probably won't, but they could.

Thanks for the hint, I changed this so the user should decide if its okay with him. What do you think? http://trac.macports.org/projects/macports/changeset/32138

Perhaps we should make those fatal again and add an option to port(1) for ignoring warnings, like `port --I-know-what-Im-doing install foo'.

I think it's okay to make it fatal if destroot.violate_mtree is not true (I'm not sure if this is already the case). But if the maintainer thinks it's necessary we should respect his/her decision.

Regards,

-Markus

Thanks, Simon

*) for whatever reason

PS: You have a duplicate "set" in the 1st sentence.

Thanks, I fixed it. -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229

On Mon, Dec 17, 2007 at 05:00:52PM -0600, Ryan Schmidt wrote:

Please, no. It was that way in MacPorts 1.5.1, and we had to quickly release 1.5.2 to make it non-fatal due to all the reports coming in. I still see reports coming in every once in awhile about ports violating the mtree without using destroot.violate_mtree. Until we can prove that only a very few ports (or no ports) violate the mtree without saying so, we should not make it fatal. And since we do not have any automated builds right now and therefore no way to know how many ports still violate the mtree without saying so, we should not make this fatal at all.

Basically, making this a fatal error would inconvenience the user, when we mean instead to alert the maintainer. Inconveniencing the user is not a good idea. We should be striving to make MacPorts more user-friendly, not less.

Hi Ryan, I think you are right. We shouldn't change this at the moment. But to make it easier for the maintainer, would it be possible to generate a bigger warning? I often miss it when using -d. Maybe something like this: *************************************************************************** * * * This port violates the MacPorts file hierarchy. Please check if this is * * intended and use destroot.violate_mtree if necessary. * * * *************************************************************************** Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229