destroot.violate_mtree and warning during install
Hi, 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? Thanks for your help, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229
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 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 Thanks, Simon -- + privacy is necessary + using http://gnupg.org + public key id: 0x6115F804EFB33229
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 Dec 17, 2007, at 2:05 PM, Markus Weissmann wrote:
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 don't think that would be good (as apache module ports, for example, violate the mtree but don't put anything outside of ${prefix} and should be allowed to continue to do this, I think). It might be a good idea for any ports that want to install stuff outside of ${prefix}, though (aside from acceptable stuff, like the launchd symlinks, etc.) -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
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 Dec 17, 2007, at 13:50, Simon Ruderich wrote:
On Mon, Dec 17, 2007 at 08:05:40PM +0100, Markus Weissmann wrote:
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.
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.
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
Citando Simon Ruderich :
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. * * * ***************************************************************************
Such a message should only be read by the developper. Maybe there should be a special developper flag with trace mode, lint, and for which violation of mtree would be fatal. Maybe this is debug mode however. Maintainers of a package should then be strongly encouraged to use this flag when building their own ports but users would have the kind version that installs anyway (and may wreck their system if they have not been quiet enough during the year). Emmanuel
participants (5)
-
Daniel J. Luke
-
Emmanuel Hainry
-
Markus Weissmann
-
Ryan Schmidt
-
Simon Ruderich