Re: symlinks replaced by directories and vice versa
Brian May <[EMAIL PROTECTED]> wrote: > If you want to replace a directory with a symlink, and the directory > still contains files, what do you do with these files? Indeed, symlinks colliding with existing directories should give an error while package installation. And IMHO this could even be done pre etch, since this should just not occur. regards Mario -- It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories instead of theories to suit facts. -- Sherlock Holmes by Arthur Conan Doyle -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: symlinks replaced by directories and vice versa
Mario 'BitKoenig' Holbe <[EMAIL PROTECTED]> writes: > Hello, > > IMHO, one of the most frequently re-appearing issues in package-upgrades > is symlinks in previous package versions replaced by directories in > current versions and vice versa. > Although the Debian policy clearly states in 6.6 (4) "A directory will > never be replaced by a symbolic link to a directory or vice versa" it > seems to me that many package maintainers cannot deal well with this > behaviour or just don't know it. Afaik dpkg does not remember what is a link to and what is a directory in a package so it can't properly track that change in the package and can't differentiate it from the admin moving and linking a directory. That is the bad news. Now the good news. I think moving and linking directories could be forbidden and be replaced by moving and mount --bind. It avoids the pritfalls of symlinked dirs completly and provides all the features. ... > However, since this is such a frequent source of bugs and since so many > package maintainers seem not to be able to deal well with it, I'm asking > myself, if it wouldn't make sense to change this behaviour to something > which is more native to maintainers - i.e. automagically replace > symlinks by directories and vice versa (which would natively equal a > package upgrade to a package removal followed by an installation of the > new version) or abort package installation if it occurs or something > like this. I think post etch this could be a good idea. But someone has to dig into dpkg to implement it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: symlinks replaced by directories and vice versa
On Sat, Dec 09, 2006 at 01:34:51PM +0100, Loïc Minier <[EMAIL PROTECTED]> wrote:
> On Sat, Dec 09, 2006, Mario 'BitKoenig' Holbe wrote:
> > However, since this is such a frequent source of bugs and since so many
> > package maintainers seem not to be able to deal well with it, I'm asking
> > myself, if it wouldn't make sense to change this behaviour to something
> > which is more native to maintainers - i.e. automagically replace
> > symlinks by directories and vice versa (which would natively equal a
> > package upgrade to a package removal followed by an installation of the
> > new version) or abort package installation if it occurs or something
> > like this.
>
> I agree it's counter-intuitive. I seem to recall someone told me it
> was a feature of dpkg which allows local admin to e.g. ln -s /bigdisk
> /usr/share. I'm not sure this is the correct explanation, but if it
> is, then perhaps it would make more sense to support this functionality
> at the dpkg level directly, perhaps in a similar fashion to diversions
> ("I want that anything that would be installed to /usr/share be
> installed in $otherdir" sounds similar to what diversion currently do).
Directory diversions is a very old feature request See #30126 and #33263.
And that could be sufficient to solve the issue.
Mike
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: symlinks replaced by directories and vice versa
On Sat, Dec 09, 2006, Mario 'BitKoenig' Holbe wrote:
> However, since this is such a frequent source of bugs and since so many
> package maintainers seem not to be able to deal well with it, I'm asking
> myself, if it wouldn't make sense to change this behaviour to something
> which is more native to maintainers - i.e. automagically replace
> symlinks by directories and vice versa (which would natively equal a
> package upgrade to a package removal followed by an installation of the
> new version) or abort package installation if it occurs or something
> like this.
I agree it's counter-intuitive. I seem to recall someone told me it
was a feature of dpkg which allows local admin to e.g. ln -s /bigdisk
/usr/share. I'm not sure this is the correct explanation, but if it
is, then perhaps it would make more sense to support this functionality
at the dpkg level directly, perhaps in a similar fashion to diversions
("I want that anything that would be installed to /usr/share be
installed in $otherdir" sounds similar to what diversion currently do).
> I'm not sure if this is the right list to discuss that
(perhaps the dpkg list indeed)
--
Loïc Minier <[EMAIL PROTECTED]>
"I have no strong feelings one way or the other." -- Neutral President
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
symlinks replaced by directories and vice versa
Hello, IMHO, one of the most frequently re-appearing issues in package-upgrades is symlinks in previous package versions replaced by directories in current versions and vice versa. Although the Debian policy clearly states in 6.6 (4) "A directory will never be replaced by a symbolic link to a directory or vice versa" it seems to me that many package maintainers cannot deal well with this behaviour or just don't know it. I personally filed lots of bug reports against lots of packages in the past regarding this issue. Unfortunately, this issue is typically not so easy to detect soon when it appears. Instead, such cases linger around a long time until eons later some unexpected overwrites happen or until you try to remove a package or something like this. I personally just detect them soon because I run daily filesystem-modification checks (in conjunction with debsums) and thus notice quickly when new files appear where no files out of the package managers scope should exist. Unfortunately, the issue appeared so often that at some point in the past I just resigned and gave up to file bug reports because of it and instead I began just to fix it on my systems locally and forget about it. However, since this is such a frequent source of bugs and since so many package maintainers seem not to be able to deal well with it, I'm asking myself, if it wouldn't make sense to change this behaviour to something which is more native to maintainers - i.e. automagically replace symlinks by directories and vice versa (which would natively equal a package upgrade to a package removal followed by an installation of the new version) or abort package installation if it occurs or something like this. I'm not sure if this is the right list to discuss that, but perhaps it's the best list to collect notions from others (especially package maintainers) about it. I know there *are* maintainers out there who *know* about this case and *do* handle it carefully and sometimes even *use* it intentionally, like the sendmail maintainer (although even there it makes problems because of undetected overwrites). However, I have never seen any single case where it was really necessary to package something this way. regards Mario -- talk softly and carry a keen sword -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
