[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> > 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.



Torsten Landschoff           Bluehorn@IRC               <torsten@debian.org>
           Debian Developer and Quality Assurance Committee Member

Reply to: