Re: Bug#49793: Debian Bugs information: logs for Bug#49793
Hi Marco,
Thanks for your quick response.
On Thu, Jan 06, 2000 at 08:05:03PM +0000, Marco Budde wrote:
> > > Ok, than please fill a bug report against these packages. doc/HTML
> > > shouldn´t be used by other packages than dhelp. Could you please
> > > send me the names of the packages (versions) and maybe the names
> > > of their Debian maintainers?
>
> I´m still waiting for the email addresses.
At least the KDE packages use that directory. They are not officially part
of Debian yet, but the maintainer is Stephan Kulow <coolo@kde.org>.
> > Why the heck can a package maintainer just claim a directory for his
> > package?
>
> You can always do that. All programs need directories for the data
> itself. You should never use a subsubdirectory like /usr/doc/foo
> without asking the person already using the directory.
Wait! I can put stuff in there. But that directory will not be deleted.
So while I agree that every package can just allocate a file it will
not normally overwrite anything during dpkg installation and nothing
not belonging to the package will be removed on deinstallation.
> When you put files in /var/spool/{mail, news, ...} you could
> cause the same problems.
/var is a completely different issue. var is variable, usr not. And spool
file are obviously deleted at some time.
> Maybe Debian needs a database where we collect the names of such
> directories. But at the moment there is no such database. So the
> only solution for such name space problems is: ask when using
> directories of other packages.
Point taken. I guess we have to do something about this in the long
term since Debian will get rather messy otherwise.
> Right, the latest versions of dhelp creates such README files.
Good. I would agree downgrading the bug to severity wishlist then. BTW:
I don't have dhelp installed here currently. Does dhelp ever put directories
in that path? If not could you please make it remove only files from there
trying a rmdir afterwards?
> > If the directory were /usr/share/doc/dhelp or similar but I don't expect
> > anything to delete from /usr/share/doc/HTML.
>
> Why not? dhelp is using this directory in this way for *years*.
Win95 is crashing on me for years. Do you expect me to applaud to that because
it did that for years?
This issue is both good and bad - the good thing is that dhelp work that
seamless I did never know it uses that directory. The bad thing this
being unnoticed for some time.
Hmm, I guess I should scan all postrm scripts for something like rm -Rf...
> > They installed some HTML documents in that directory thinking this is okay.
>
> Users should never install files in /usr/doc. They should use
> /usr/local/doc.
The reason to install it into /usr/share/doc/HTML was that it is accessible
by the default apache installation from there. You can get all docs per
http://localhost/doc which is rather cool.
Would be even better if everything in there is registered per dhelp/doc-base.
> > I agree that the README will solve that problem. Still I am all for a
> > better solution.
>
> Right: Debian needs a better organisation to prevent such name space
> problems. We´ve got the same problem with files in /usr/bin for example.
Show me the package doing rm -Rf on /usr/bin please.
> > If dhelp needs some database of the files it generated
> > to be able to delete only those files I could help to write such a feature.
>
> In fact I´m thinking about a new implementation of dhelp for the
> next Debian 2.3 release.
Cool. BTW: Forgot to mention that I really like dhelp the way it is. I just
strongly oppose to some program blindly deleting a directory because it is
his.
> > The current behaviour is unintuitive and imho this is bad for Debian.
>
> I don´t think so.
That's your right. Let's wait what other developers say. Excuse me if
I am the exception and everybody else thinks this behaviour is okay.
Thanks
Torsten
--
Torsten Landschoff Bluehorn@IRC <torsten@debian.org>
Debian Developer and Quality Assurance Committee Member
Reply to: