-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> "Chris" == Chris Waters <[EMAIL PROTECTED]> writes:
[SNIP]
Chris> The sysadmin is really supposed to stick to /usr/local and
Chris> /etc (and maybe /opt). I have to admit that I've been
Chris> seriously tempted to just silently del
Manoj Srivastava wrote:
> Some cases prompting is benefitial, if it allows the system to
> be more responsive to the users needs. All prompting is not bad. In
> this case, unknown files in a directory which needs to go away has to
> be handled. One can't just remove the files (they may b
On Fri, Oct 08, 1999 at 04:03:32PM +0200, Remco Blaakmeer wrote:
> if [ -d /usr/doc -a ! -h /usr/doc ]; then
>
> This means "if /usr/doc is a directory AND /usr/doc is NOT a symlink,
> then...".
s/-h/-L/
They mean the same thing but -L is far more intuitive.
--
G. Branden Robinson
Hi,
>>"Brian" == Brian May <[EMAIL PROTECTED]> writes:
Joeyh> That seems quite difficult to do. Suppose you have package a
Joeyh> that is being upgraded and package b that happens to install
Joeyh> docs into /usr/doc/a.
This is not an issue, since the files thsat package b installs
sh
On Fri, 8 Oct 1999, Stefan Gybas wrote:
> Manoj Srivastava wrote:
>
> > if [ -d /usr/doc ]; then
> > # Well, we still need to handle this, at least for the time being
[...]
>
> All this will fail if at some time in the future /usr/doc is a symlink to
> /usr/share/doc.
Then replace t
Manoj Srivastava wrote:
> if [ -d /usr/doc ]; then
> # Well, we still need to handle this, at least for the time being
> if [ -d /usr/share/doc/$package_name ]; then
> # So the new doc dir exists, goody
> if [ -d /usr/doc/$package_name ]; then
>
On Fri, Oct 08, 1999 at 04:08:08AM +1000, Manoj Srivastava wrote:
> Brian> I don't think it is that easy just to remove the old /usr/doc
> Brian> directory (for the same reason somebody told me you can't just
> Brian> move the files from /usr/doc to /usr/share/doc).
>
> Please elaborate
Hi,
>>"Joey" == Joey Hess <[EMAIL PROTECTED]> writes:
Joey> I dislike this bit because evey instance I've seen of their being a
.dhelp
Joey> file left was a bug in the package.
Is there a problem in removing the .dhelp file, no matter
whose but it is? One could add a message asking a
Hi,
>>"Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> I am guessing that all of these issues have been fully discussed,
Brian> however, I think that some people might be oversimplifing the issue...
One would appreciate details, then.
Brian> I don't think it is that easy just
>That was my first reaction, but it only involves prompting if the
>sysadmin has been messing around where, arguably, he or she really
>shouldn't. IOW, there *shouldn't* be files there, so we're only
>prompting in a case that *should* never arise.
>
>The sysadmin is really supposed to stick to /us
Joey Hess <[EMAIL PROTECTED]> writes:
> Manoj Srivastava wrote:
> > Ask the user of one should move the old files to the new location
> > if yes, copy files over, with backup, remove old dir
> > else abort with an error
> I dislike this bit because it involves prompting.
Th
Manoj Srivastava wrote:
> if /usr/doc exists, and /usr/share/doc/$pkg/ dir also exists (if
> it does not, we can't create a symlink)
> if /usr/doc/$pkg/ still exists (yikes),
>remove any .dhelp files, and see of that solves it
I dislike this bit because evey instance I've seen
On Wed, Oct 06, 1999 at 03:01:05PM -0500, Manoj Srivastava wrote:
> I have a shell script that does the above algorithm, if people
> are interested.
Yes.
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%
""
Hi,
I have also encountered this in my packages, and I found that
silently failing to create the symlink was not to my liking. My
solutions was:
if /usr/doc exists, and /usr/share/doc/$pkg/ dir also exists (if
it does not, we can't create a symlink)
if /usr/doc/$pkg/ still e
Ulf Jaenicke-Roessler wrote:
> So maybe, just like dpkg, debhelper could output a warning if it doesn't/
> cannot create the link? At least for a certain period of time, till the
> migration is finished. I think this would even help package maintainers to
> find the bug when they test their package
Joey Hess wrote:
> > For example, I found that libpanel-applet0 leaves a single file in its
> > old doc directory (currently unexplainable and unreproducable by the
> > maintainer) preventing the compatibility link to be created.
[...]
> > Another example is the latest 'time' package, which do
Brian May wrote:
> As an alternative, I would suggest moving any files from /usr/doc to
> /usr/share/doc. Of course, this would have to be done after any dpkg
> managed files under /usr/doc have already been deleted, especially if
> upgrading.
That seems quite difficult to do. Suppose you have pac
Ulf Jaenicke-Roessler wrote:
> Package: debhelper
> Version: N/A
> Severity: wishlist
> For example, I found that libpanel-applet0 leaves a single file
> in its old doc directory (currently unexplainable and unreproducable
> by the maintainer) preventing the compatibility link to be created.
Ulf Jaenicke-Roessler <[EMAIL PROTECTED]> wrote:
> I'd like to mention some general problems with packages migrating
> from /usr/doc to /usr/share/doc. Some of these problems exist,
> although they are very hard to explain and/or to reproduce.
>
> For example, I found that libpanel-applet0 le
> The question is, should the migration, for packages which want to
> do it at all, be enforced? I.e., should the old doc directory be
> deleted (rm -rf) before dh_installdocs tries to create the link?
> 'ln -snf' (no dereference) might help for wrong links.
I am confused. Are you talking about bu
Package: debhelper
Version: N/A
Severity: wishlist
(I'm not sure, if this is the right form to handle this, but I
didn't know better. Sorry, if this might not be okay)
Hi,
I'd like to mention some general problems with packages migrating
from /usr/doc to /usr/share/doc. Some of these proble
21 matches
Mail list logo
