Santiago Vila wrote:
> /opt is created by default on every new install since Debian 3.0.
>
> It is not part of the package itself to give users the freedom to
> remove it if they wish and not see it recreated at every base-files
> upgrade, as no part of Debian needs it.
That makes sense.
> If you remove it but you still need it, why do you blame base-files?
Here is the scenario I was thinking of. Suppose my /usr/local
partition is large, so I decide I want /opt to be at /usr/local/opt.
So:
# rmdir /opt
# ln -s usr/local/opt /opt
(This step is where the sysadmin has an escape route; see below[*].)
Now I install two packages under /opt, one using a Debian-format
package and another using a tarball.
# apt-get install package-with-files-under-opt
# cd /
# tar -xf ~/tarball-with-files-under-opt.tar.gz
Eventually I decide I don't like that package with files under /opt:
# apt-get remove package-with-files-under-opt
What happens? As discussed at [1], /opt is removed.
> I don't see why this is reported as a bug against base-files.
A few possible fixes:
1. Make sure there is always a package containing /opt (e.g.,
base-files). This way, dpkg would never have reason to try to
remove the symlink.
2. Leave /opt out of the files list when generating
package-with-files-under-opt.
3. Teach dpkg to remember whether a directory already existed before
the first package including it was installed, and do not remove
such directories when the last package including them is removed.
4. Encourage sysadmins to use bind mounts instead of symlinks for
this purpose.
All are incomplete or have downsides. (1) prevents the sysadmin from
removing /opt, as you mentioned. (2) complicates the package creation
procedure, so much so that I'm not sure whether it would work.
(3) would prevent directories first created in maintainer scripts and
later incorporated into the files list from being cleaned up on
removal. (4) has no clear downside --- what would be a good document
to advertise this in?
[1] http://bugs.debian.org/182747
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
