How to see just mtree violations?
Not to say that I liked it better when mtree violations were fatal, but when they were, it was at least possible to easily notice the mtree violation. Now that it's only a warning in debug mode, it's too easily swallowed up by the deluge of other debug messages being printed before and after the mtree check. Before, we have configure, make and make install output, and after, we have activation output. In even medium-sized software packages, these can easily be hundreds of lines. We have the -t switch which we can turn on separately to activate trace mode, which is helpful for discovering undeclared dependencies. Is there a way that we could somehow see just the mtree violations, without all the other verbose/debug info?
Ryan Schmidt wrote:
Not to say that I liked it better when mtree violations were fatal, but when they were, it was at least possible to easily notice the mtree violation. Now that it's only a warning in debug mode, it's too easily swallowed up by the deluge of other debug messages being printed before and after the mtree check. Before, we have configure, make and make install output, and after, we have activation output. In even medium-sized software packages, these can easily be hundreds of lines.
Can't you grep for "mtree" or "violation", when doing the destroot ?
We have the -t switch which we can turn on separately to activate trace mode, which is helpful for discovering undeclared dependencies. Is there a way that we could somehow see just the mtree violations, without all the other verbose/debug info?
It would be helpful with such a "verify installed mtree" switch, yes. --anders
On 2007-08-20 03:36:38 -0500, Ryan Schmidt wrote:
We have the -t switch which we can turn on separately to activate trace mode, which is helpful for discovering undeclared dependencies. Is there a way that we could somehow see just the mtree violations, without all the other verbose/debug info?
Couldn't a Portfile state that it doesn't violate mtree, so that mtree violations are fatal in such cases? -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Aug 20, 2007, at 06:41, Vincent Lefevre wrote:
On 2007-08-20 03:36:38 -0500, Ryan Schmidt wrote:
We have the -t switch which we can turn on separately to activate trace mode, which is helpful for discovering undeclared dependencies. Is there a way that we could somehow see just the mtree violations, without all the other verbose/debug info?
Couldn't a Portfile state that it doesn't violate mtree, so that mtree violations are fatal in such cases?
Uhhhhh...... I think we should assume a port does not violate the mtree. And... that doesn't seem to address the problem I'm trying to solve. I maintain a couple dozen ports, and I would like to reinstall each of them and ensure there are no mtree violations. I'm just looking for an easy way to see the mtree errors, if there are any. I'll try using debug mode with grep, as Anders suggested.
On Aug 20, 2007, at 7:41 AM, Vincent Lefevre wrote:
On 2007-08-20 03:36:38 -0500, Ryan Schmidt wrote:
We have the -t switch which we can turn on separately to activate trace mode, which is helpful for discovering undeclared dependencies. Is there a way that we could somehow see just the mtree violations, without all the other verbose/debug info?
Couldn't a Portfile state that it doesn't violate mtree, so that mtree violations are fatal in such cases?
If I'm reading you correctly, you're proposing a Portfile only be accepted as clean if it specifically states it doesn't violate the mtree? If so, such functionality would require us going through every single one of our Portfiles and adapting them accordingly... which is needless to say a daunting task. To increase mtree violations visibility, at least for the time being, I propose promoting them to verbose output. -jmpp
On Aug 27, 2007, at 22:39, Juan Manuel Palacios wrote:
On Aug 20, 2007, at 7:41 AM, Vincent Lefevre wrote:
On 2007-08-20 03:36:38 -0500, Ryan Schmidt wrote:
We have the -t switch which we can turn on separately to activate trace mode, which is helpful for discovering undeclared dependencies. Is there a way that we could somehow see just the mtree violations, without all the other verbose/debug info?
Couldn't a Portfile state that it doesn't violate mtree, so that mtree violations are fatal in such cases?
If I'm reading you correctly, you're proposing a Portfile only be accepted as clean if it specifically states it doesn't violate the mtree? If so, such functionality would require us going through every single one of our Portfiles and adapting them accordingly... which is needless to say a daunting task.
To increase mtree violations visibility, at least for the time being, I propose promoting them to verbose output.
It turns out that if you just install the port normally, with neither debug nor verbose output, mtree violations are already easily visible. So no change to base is necessary.
On 2007-08-27 23:39:04 -0400, Juan Manuel Palacios wrote:
If I'm reading you correctly, you're proposing a Portfile only be accepted as clean if it specifically states it doesn't violate the mtree? If so, such functionality would require us going through every single one of our Portfiles and adapting them accordingly... which is needless to say a daunting task.
Their maintainers could do that (if the warning isn't sufficient for them).
To increase mtree violations visibility, at least for the time being, I propose promoting them to verbose output.
mtree violations aren't much visible if they aren't fatal. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On 2007-08-28 01:50:30 -0500, Ryan Schmidt wrote:
It turns out that if you just install the port normally, with neither debug nor verbose output, mtree violations are already easily visible. So no change to base is necessary.
The problem is that when one uses debug/verbose output, one gets so much output that it is not always possible to see mtree violations. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On 29.08.2007, at 15:30, Vincent Lefevre wrote:
On 2007-08-27 23:39:04 -0400, Juan Manuel Palacios wrote:
If I'm reading you correctly, you're proposing a Portfile only be accepted as clean if it specifically states it doesn't violate the mtree? If so, such functionality would require us going through every single one of our Portfiles and adapting them accordingly... which is needless to say a daunting task.
Their maintainers could do that (if the warning isn't sufficient for them).
Portfiles that conform to our standards should be the norm, so only violators should have to indicate their non-standard behavior. Otherwise this would be like having to mark all transports that do NOT carry nuclear waste; every waste-bin would needs to carry a "no- biohazard" sign...
To increase mtree violations visibility, at least for the time being, I propose promoting them to verbose output.
mtree violations aren't much visible if they aren't fatal.
Well, I actually wanted to do this initially, leading to many angry people who were caught off-guard with non-functional ports. The current state is that a violation is displayed via 'ui_msg', so everyone will see it. We can switch this behavior to a fatal one in one of our next releases, giving people a bit of time to realize those warnings and perhaps even fix them... Regards, -Markus --- Markus W. Weissmann http://www.mweissmann.de/
On 2007-08-29 15:43:35 +0200, Weissmann Markus wrote:
Portfiles that conform to our standards should be the norm, so only violators should have to indicate their non-standard behavior.
OK, so mtree violations should be fatal.
Well, I actually wanted to do this initially, leading to many angry people who were caught off-guard with non-functional ports.
As you said above, maintainers could add something to indicate their non-standard behavior (or users could report bugs).
The current state is that a violation is displayed via 'ui_msg', so everyone will see it.
Not in case of verbose output.
We can switch this behavior to a fatal one in one of our next releases, giving people a bit of time to realize those warnings and perhaps even fix them...
It would be better to do it now, or add a switch to the port command (which could be removed later) to make mtree violations fatal. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Aug 29, 2007, at 09:10, Vincent Lefevre wrote:
On 2007-08-29 15:43:35 +0200, Weissmann Markus wrote:
Portfiles that conform to our standards should be the norm, so only violators should have to indicate their non-standard behavior.
OK, so mtree violations should be fatal.
Maybe -- eventually -- many months from now months -- once everyone has had the opportunity to fix the portfiles. But, see below for reasons not to.
Well, I actually wanted to do this initially, leading to many angry people who were caught off-guard with non-functional ports.
As you said above, maintainers could add something to indicate their non-standard behavior (or users could report bugs).
The current state is that a violation is displayed via 'ui_msg', so everyone will see it.
I notice now that the problem is that it only shows the top-level directory which is being violated, not the file which is causing the violation: Warning: violation by /usr Then I have to "sudo port uninstall" and then "sudo port -dv destroot" in order to see the actual files. ("sudo port -dv install" would print too much info afterward that I wouldn't see the mtree info.)
Not in case of verbose output.
We can switch this behavior to a fatal one in one of our next releases, giving people a bit of time to realize those warnings and perhaps even fix them...
It would be better to do it now, or add a switch to the port command (which could be removed later) to make mtree violations fatal.
Please don't make the notices fatal for everyone now. Port maintainers need time to discover that their ports violate the mtree and figure out how to fix it. mtree violations were fatal in 1.5.1 resulting in a torrent of users complaining about ports they couldn't install and we had to do a quick 1.5.2 to reduce them to warnings so that people could continue using the software they wanted to use. I don't think anybody realized these mtree errors would be occurring (except the author of the feature) until the messages started pouring in. These messages are important to developers, but users should not be inconvenienced by them. Given that more than half our ports are currently unmaintained (2111 out of 4202), I'm unconvinced that mtree violations should ever be made fatal. Doing so could inconvenience the users of many of our ports, and give them the impression that MacPorts is broken or not ready for prime-time, impressions I think we should strive to reduce, not increase.
On 2007-08-29 23:29:11 -0500, Ryan Schmidt wrote:
Please don't make the notices fatal for everyone now. Port maintainers need time to discover that their ports violate the mtree and figure out how to fix it. mtree violations were fatal in 1.5.1 resulting in a torrent of users complaining about ports they couldn't install and we had to do a quick 1.5.2 to reduce them to warnings so that people could continue using the software they wanted to use. I don't think anybody realized these mtree errors would be occurring (except the author of the feature) until the messages started pouring in. These messages are important to developers, but users should not be inconvenienced by them.
Given that more than half our ports are currently unmaintained (2111 out of 4202), I'm unconvinced that mtree violations should ever be made fatal. Doing so could inconvenience the users of many of our ports, and give them the impression that MacPorts is broken or not ready for prime-time, impressions I think we should strive to reduce, not increase.
Yes, but you didn't answer to the main point (that was already in my first message): in the meantime, what about making this configurable? -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
participants (5)
-
Anders F Björklund
-
Juan Manuel Palacios
-
Ryan Schmidt
-
Vincent Lefevre
-
Weissmann Markus