Hello, Peter!
> That's not quite it either. If I install something into
> /opt/foo-0.99/{bin,lib,include} and then it only removes the bin, lib, and
> include parts, then it's arguably being less than helpful.
IMHO you install something into /opt/foo-0.99 it's because you don't trust
your packag
> "Pavel" == Pavel Roskin <[EMAIL PROTECTED]> writes:
Pavel> Let's make "missing" handle "mkdir -p" to begin with.
That would be fine with me.
Pavel> I still insist that no directories should be removed by "make
Pavel> uninstall" unless they defininely belong to the package being
Pavel> uni
Hello, Tom!
> I think we should not introduce more utilities. We have way too many
> already. How about reimplementing this as a patch to "missing"? Then
> we can do "missing rmdir -p". Having AM_INIT_AUTOMAKE look for "rmdir
> -p" would also be appropriate...
Let's make "missing" handle "mk
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> The added beauty of this approach would be that `rminstalldirs'
Peter> would be to `rmdir -p' what `mkinstalldirs' is now to `mkdir
Peter> -p'. A possible (though perhaps not perfect) implementation of
Peter> rminstalldirs is at
> "Peter" == Peter Eisentraut <[EMAIL PROTECTED]> writes:
Peter> Might part of that perceived uselessness come from the fact
Peter> that it doesn't remove the directories?
I don't think so. I think that one big reason is that you have to
keep (the skeleton of) the build tree around for "uni
On Mon, May 15, 2000 at 11:30:37AM -0700, Masterson, David wrote:
> An option (or environment variable) setting for "mkuninstalldirs"? And
> perhaps the default "do nothing"? Or simply print out "I'd like to remove
> $x dir" and leave it to the sysadmin to decide?
If you *must* implement this,
Tom Tromey writes:
> Assar> d) remove all the levels that are empty
>
> This is what I've always wanted to do.
> I've never gotten around to it though. It never seemed all that
> important, given the relative uselessness of "uninstall".
Might part of that perceived uselessness come from the fa
Assar Westerlund writes:
> b) just remove the directories that were created during `make install'
If you `make install' twice then the second time the directories aren't
created anymore, so the `make uninstall' would not attempt to remove them.
Not good.
> c) remove the last level of directory
An option (or environment variable) setting for "mkuninstalldirs"? And
perhaps the default "do nothing"? Or simply print out "I'd like to remove
$x dir" and leave it to the sysadmin to decide?
-Original Message-
From: Pavel Roskin [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 15, 2000 11
Hello, David!
> Therefore, I think I'd suggest, as "make install" has a call to
> "mkinstalldirs" before the loop to install files, perhaps "make uninstall"
> should have a call to "mkuninstalldirs" after the loop to remove files. The
> "mkuninstalldirs" script can handle the cleanup of supposed
Whoops, thought this should also go to the mailing list for more general
comment.
-Original Message-
From: Masterson, David
Sent: Monday, May 15, 2000 10:25 AM
To: 'François Pinard'; Masterson, David
Subject: RE: shall `make uninstall' remove directories?
How about "rmdir" to remove em
On Mon, May 15, 2000 at 11:20:30AM -0400, Pavel Roskin wrote:
: > I say, remove /usr/local and even /usr if possible ;)
:
: But what if /usr/local was empty but existed before "make install" ?
: What if /usr/local is a mount point?
Nuke it anyway...
I was of course joking in my original remark,
"Lars J. Aas" <[EMAIL PROTECTED]> writes:
> I say, remove /usr/local and even /usr if possible ;)
Yet, not if they are symbolic links :-).
--
François Pinard http://www.iro.umontreal.ca/~pinard
Hello!
> I say, remove /usr/local and even /usr if possible ;)
But what if /usr/local was empty but existed before "make install" ?
What if /usr/local is a mount point?
Automake is not a system administration tool. The only real reason to
remove a directory is because the package indicates that
> : Is there any value to keeping /usr/local/share, if it's empty?
> : Theorectically yes, but the next package that needs it will recreate it
> : anyway. Implementation would be simplified with this assumption.
>
> I say, remove /usr/local and even /usr if possible ;)
Why stop there? ;-))
Hello!
> a) always remove the directories
> b) just remove the directories that were created during `make install'
> c) remove the last level of directory if it's empty
> d) remove all the levels that are empty
e) remove only the directories specific to the package (pkgdatadir,
pkglibdir, pkginc
On Mon, May 15, 2000 at 02:17:24PM +0200, Peter Eisentraut wrote:
: On 15 May 2000, Didier Verna wrote:
: > > Assar> d) remove all the levels that are empty
: > >
: > > This is what I've always wanted to do.
: >
: > You mean `levels' that belong to the package itself, right ? I mean
: >
Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> On 15 May 2000, Didier Verna wrote:
>
> > > Assar> d) remove all the levels that are empty
> > >
> > > This is what I've always wanted to do.
> >
> > You mean `levels' that belong to the package itself, right ? I mean
> > /usr/local/share/a
On 15 May 2000, Didier Verna wrote:
> > Assar> d) remove all the levels that are empty
> >
> > This is what I've always wanted to do.
>
> You mean `levels' that belong to the package itself, right ? I mean
> /usr/local/share/automake, but not /usr/local/share for instance.
Is there any
[ Cc'ed to automake, see last point ]
Akim Demaille wrote:
> it seems that the primary issue is the fact that some macros need to be
> before AC_INIT, while most others should not.
correct.
> all (y)our troubles will vanish if *any* macro works after AC_INIT.
correct.
> I'v
Tom Tromey wrote:
> > "Assar" == Assar Westerlund <[EMAIL PROTECTED]> writes:
>
> Assar> Currently automake does not remove directories in `make
> Assar> uninstall' and I did not find any text regarding this in the
> Assar> GNU coding guidelines either. So what's the right thing to do
> Ass
21 matches
Mail list logo
