destroot.violate_mtree and warning during install
Emmanuel Hainry
milosh at macports.org
Wed Dec 19 14:04:14 PST 2007
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
More information about the macports-dev
mailing list