Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   dpkg, symlinks, directories (http://www.linux-archive.org/debian-development/708291-dpkg-symlinks-directories.html)

Vincent Bernat 09-29-2012 09:59 AM

dpkg, symlinks, directories
 
Hi!

In roundcube package, I am turning existing directories to symlinks and
symlinks into directories. It seems that dpkg does not like that:
symlinks are not replaced with the appropriate directories. I didn't
find anything about this in the documentation. How should I handle such
cases?
--
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)

Salvatore Bonaccorso 09-29-2012 10:35 AM

dpkg, symlinks, directories
 
Hi Vincent

On Sat, Sep 29, 2012 at 11:59:38AM +0200, Vincent Bernat wrote:
> In roundcube package, I am turning existing directories to symlinks and
> symlinks into directories. It seems that dpkg does not like that:
> symlinks are not replaced with the appropriate directories. I didn't
> find anything about this in the documentation. How should I handle such
> cases?

This is indeed intentional, that dpkg never replaces directories with
symlinks if directory is present, see [1] and [2] (under 4.).

[1]: http://bugs.debian.org/404850
[2]: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

Andreas Beckmann recently is filling many of these bugs discovered by
piuparts runs (updating Squeeze -> Wheezy). Most common approach there
is to do the substitution in postinst, in case the directory is there.
See for example [3].

[3]: http://bugs.debian.org/687859

Does this helps?

Regards,
Salvatore

Vincent Bernat 09-29-2012 10:39 AM

dpkg, symlinks, directories
 
❦ 29 septembre 2012 11:59 CEST, Vincent Bernat <bernat@debian.org>*:

> In roundcube package, I am turning existing directories to symlinks and
> symlinks into directories. It seems that dpkg does not like that:
> symlinks are not replaced with the appropriate directories. I didn't
> find anything about this in the documentation. How should I handle such
> cases?

As an illustration, look at roundcube-core 0.3.1-6 (squeeze):

#v+
# dpkg -c roundcube-core_0.3.1-6_all.deb | grep plugins
drwxr-xr-x root/root 0 2010-10-18 21:18 ./var/lib/roundcube/plugins/
drwxr-xr-x root/root 0 2009-10-31 13:20 ./var/lib/roundcube/plugins/filesystem_attachments/
-rw-r--r-- root/root 5140 2009-10-03 19:12 ./var/lib/roundcube/plugins/filesystem_attachments/filesystem_attachments.php
lrwxrwxrwx root/root 0 2010-10-18 21:18 ./usr/share/roundcube/plugins -> /var/lib/roundcube/plugins
#v-

And for roundcube-core 0.7.1-1~bpo60+1 (squeeze-backports):

#v+
# dpkg -c roundcube-core_0.7.1-1~bpo60+1_all.deb | grep plugins | remove-some-output-by-hand
drwxr-xr-x root/root 0 2012-04-28 07:39 ./usr/share/roundcube/plugins/
drwxr-xr-x root/root 0 2012-04-28 07:39 ./usr/share/roundcube/plugins/jqueryui/
drwxr-xr-x root/root 0 2012-01-17 07:50 ./usr/share/roundcube/plugins/filesystem_attachments/
-rw-r--r-- root/root 5219 2012-01-17 07:50 ./usr/share/roundcube/plugins/filesystem_attachments/filesystem_attachments.php
drwxr-xr-x root/root 0 2012-04-28 07:39 ./var/lib/roundcube/plugins/
lrwxrwxrwx root/root 0 2012-04-28 07:39 ./var/lib/roundcube/plugins/jqueryui -> /usr/share/roundcube/plugins/jqueryui
lrwxrwxrwx root/root 0 2012-04-28 07:39 ./var/lib/roundcube/plugins/filesystem_attachments -> /usr/share/roundcube/plugins/filesystem_attachments
#v-

But if I install 0.3.1-6, then upgrade to 0.7.1-1~bpo60+1, I get:

#v+
lrwxrwxrwx 1 root root 26 Sep 29 10:36 /usr/share/roundcube/plugins -> /var/lib/roundcube/plugins
drwxr-xr-x 4 root root 4096 Sep 29 10:37 /var/lib/roundcube/plugins
drwxr-xr-x 2 root root 4096 Sep 29 10:37 /var/lib/roundcube/plugins/filesystem_attachments
drwxr-xr-x 3 root root 4096 Sep 29 10:37 /var/lib/roundcube/plugins/jqueryui
#v-

/usr/share/roundcube/plugins was not replaced by the appropriate
directory and everything got installed in /var/lib/roundcube/plugins
instead.
--
panic("Tell me what a watchpoint trap is, and I'll then
deal with such a beast...");
2.2.16 /usr/src/linux/arch/arch/sparc/kernel/traps.c

Vincent Bernat 09-29-2012 10:47 AM

dpkg, symlinks, directories
 
❦ 29 septembre 2012 12:35 CEST, Salvatore Bonaccorso <carnil@debian.org>*:

>> In roundcube package, I am turning existing directories to symlinks and
>> symlinks into directories. It seems that dpkg does not like that:
>> symlinks are not replaced with the appropriate directories. I didn't
>> find anything about this in the documentation. How should I handle such
>> cases?
>
> This is indeed intentional, that dpkg never replaces directories with
> symlinks if directory is present, see [1] and [2] (under 4.).
>
> [1]: http://bugs.debian.org/404850
> [2]: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
>
> Andreas Beckmann recently is filling many of these bugs discovered by
> piuparts runs (updating Squeeze -> Wheezy). Most common approach there
> is to do the substitution in postinst, in case the directory is there.
> See for example [3].
>
> [3]: http://bugs.debian.org/687859
>
> Does this helps?

Thanks for the pointers! I now understand why this does not
work. Fixing in postinst is quite difficult since I have swapped
symlinks and, from the bug reports, successive installs make the
situation worst (things got installed in the wrong place).

Well, I need to work a bit on this.
--
/*
* Hash table gook..
*/
2.4.0-test2 /usr/src/linux/fs/buffer.c

Andreas Beckmann 09-29-2012 11:01 AM

dpkg, symlinks, directories
 
On 2012-09-29 12:47, Vincent Bernat wrote:
> ❦ 29 septembre 2012 12:35 CEST, Salvatore Bonaccorso <carnil@debian.org> :
>
>>> In roundcube package, I am turning existing directories to symlinks and
>>> symlinks into directories. It seems that dpkg does not like that:
>>> symlinks are not replaced with the appropriate directories. I didn't
>>> find anything about this in the documentation. How should I handle such
>>> cases?
>>
>> This is indeed intentional, that dpkg never replaces directories with
>> symlinks if directory is present, see [1] and [2] (under 4.).
>>
>> [1]: http://bugs.debian.org/404850
>> [2]: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
>>
>> Andreas Beckmann recently is filling many of these bugs discovered by
>> piuparts runs (updating Squeeze -> Wheezy). Most common approach there
>> is to do the substitution in postinst, in case the directory is there.
>> See for example [3].
>>
>> [3]: http://bugs.debian.org/687859
>>
>> Does this helps?
>
> Thanks for the pointers! I now understand why this does not
> work. Fixing in postinst is quite difficult since I have swapped
> symlinks and, from the bug reports, successive installs make the
> situation worst (things got installed in the wrong place).
>
> Well, I need to work a bit on this.

I think a working approach is:

* directory to symlink
fix it up in the postinst (at postinst, the directory should have
become "empty"):
if [ -d $X ] && [ ! -L $X ]; then
rmdir $X # bombs if not empty
ln -s $target $X
fi

* symlink to directory
remove symlinks in the preinst to avoid installing stuff at the wrong
place
test ! -L $X || rm $X

The whole process may not work properly on aborted upgrades (or even
downgrades, but these are not really supported anyway).


Andreas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 5066D4FD.8000200@abeckmann.de">http://lists.debian.org/5066D4FD.8000200@abeckmann.de

"Andrej N. Gritsenko" 09-29-2012 03:17 PM

dpkg, symlinks, directories
 
Hello!

Salvatore Bonaccorso has written on Saturday, 29 September, at 12:35:
>This is indeed intentional, that dpkg never replaces directories with
>symlinks if directory is present, see [1] and [2] (under 4.).

> [1]: http://bugs.debian.org/404850
> [2]: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

>Andreas Beckmann recently is filling many of these bugs discovered by
>piuparts runs (updating Squeeze -> Wheezy). Most common approach there
>is to do the substitution in postinst, in case the directory is there.
>See for example [3].

I supposedly not much understand how dpkg does this but my question
is - isn't it simpler to delete directory in preinst? The install then
can install the symlink in the place. Right? Redo every symlink install
in postinst seems kinda dirty for me as it duplicates package creation
steps at the time of install and may create invalid symlinks sometime.

Cheers!
Andriy.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120929151722.GB30767@rep.kiev.ua">http://lists.debian.org/20120929151722.GB30767@rep.kiev.ua

Vincent Bernat 09-29-2012 03:31 PM

dpkg, symlinks, directories
 
❦ 29 septembre 2012 17:17 CEST, "Andrej N. Gritsenko" <andrej@rep.kiev.ua>*:

>>This is indeed intentional, that dpkg never replaces directories with
>>symlinks if directory is present, see [1] and [2] (under 4.).
>
>> [1]: http://bugs.debian.org/404850
>> [2]: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase
>
>>Andreas Beckmann recently is filling many of these bugs discovered by
>>piuparts runs (updating Squeeze -> Wheezy). Most common approach there
>>is to do the substitution in postinst, in case the directory is there.
>>See for example [3].
>
> I supposedly not much understand how dpkg does this but my question
> is - isn't it simpler to delete directory in preinst? The install then
> can install the symlink in the place. Right? Redo every symlink install
> in postinst seems kinda dirty for me as it duplicates package creation
> steps at the time of install and may create invalid symlinks sometime.

In my case, this is quite complicated. I have done all this to allow a
user to install its own plugin in /var/lib/roundcube/plugins but if he
did install some plugins in /usr/share/roundcube/plugins because of the
symlink problem, I would erase them. Moreover, there are another package
that could install plugins in /usr/share/roundcube/plugins. This is
really tricky. :(
--
Make the coupling between modules visible.
- The Elements of Programming Style (Kernighan & Plauger)

Vincent Bernat 09-29-2012 03:37 PM

dpkg, symlinks, directories
 
❦ 29 septembre 2012 13:01 CEST, Andreas Beckmann <debian@abeckmann.de>*:

>> Thanks for the pointers! I now understand why this does not
>> work. Fixing in postinst is quite difficult since I have swapped
>> symlinks and, from the bug reports, successive installs make the
>> situation worst (things got installed in the wrong place).
>>
>> Well, I need to work a bit on this.
>
> I think a working approach is:
>
> * directory to symlink
> fix it up in the postinst (at postinst, the directory should have
> become "empty"):
> if [ -d $X ] && [ ! -L $X ]; then
> rmdir $X # bombs if not empty
> ln -s $target $X
> fi

In fact, because I have swapped symlinks in the past, the initial
directory does not become empty. In a version, I have:

/usr/share/roundcube/plugins -> /var/lib/roundcube/plugins
/var/lib/roundcube/plugins/plugin1

And in the new version, I have:
/var/lib/roundcube/plugins/plugin1 -> /usr/share/roundcube/plugins/plugin1
/var/lib/roundcube/plugins/plugin2 -> /usr/share/roundcube/plugins/plugin2

Unfortunately, when the user has upgraded from 1 to 2, he has:

/usr/share/roundcube/plugins -> /var/lib/roundcube/plugins
/var/lib/roundcube/plugins/plugin1
/var/lib/roundcube/plugins/plugin2

Of course, there is still a solution, but it becomes a bit complex and I
may create new bugs from it...

> * symlink to directory
> remove symlinks in the preinst to avoid installing stuff at the wrong
> place
> test ! -L $X || rm $X

This is too late since the culprit package is already in stable.
--
/*
* For moronic filesystems that do not allow holes in file.
* We may have to extend the file.
*/
2.4.0-test2 /usr/src/linux/fs/buffer.c

"Andrej N. Gritsenko" 09-29-2012 03:56 PM

dpkg, symlinks, directories
 
Hello!

Vincent Bernat has written on Saturday, 29 September, at 17:31:
> ❦ 29 septembre 2012 17:17 CEST, "Andrej N. Gritsenko" <andrej@rep.kiev.ua>*:

>>>This is indeed intentional, that dpkg never replaces directories with
>>>symlinks if directory is present, see [1] and [2] (under 4.).
>>
>>> [1]: http://bugs.debian.org/404850
>>> [2]: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-unpackphase

>>>Andreas Beckmann recently is filling many of these bugs discovered by
>>>piuparts runs (updating Squeeze -> Wheezy). Most common approach there
>>>is to do the substitution in postinst, in case the directory is there.
>>>See for example [3].

>> I supposedly not much understand how dpkg does this but my question
>> is - isn't it simpler to delete directory in preinst? The install then
>> can install the symlink in the place. Right? Redo every symlink install
>> in postinst seems kinda dirty for me as it duplicates package creation
>> steps at the time of install and may create invalid symlinks sometime.

>In my case, this is quite complicated. I have done all this to allow a
>user to install its own plugin in /var/lib/roundcube/plugins but if he
>did install some plugins in /usr/share/roundcube/plugins because of the
>symlink problem, I would erase them. Moreover, there are another package
>that could install plugins in /usr/share/roundcube/plugins. This is
>really tricky. :(

I have another case - the libfm 1.0.2 introduced a little versioning
of library so instead of /usr/include/libfm directory (in libfm <= 1.0.1)
there is a directory /usr/include/libfm-1.0 with relevant headers and a
symlink /usr/include/libfm -> libfm-1.0 which conflicts with directory
that is left empty after old package deletion. I've solved that in the
preinst script by 'rm -rf /usr/include/libfm' and I thought yet that was
a right step since upgrade 1.0.1 -> 1.0.2 went smooth.

WBR, Andriy.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120929155647.GC30767@rep.kiev.ua">http://lists.debian.org/20120929155647.GC30767@rep.kiev.ua

David Prvot 09-29-2012 04:02 PM

dpkg, symlinks, directories
 
Hi,

Le 29/09/2012 11:17, Andrej N. Gritsenko a crit :

> I supposedly not much understand how dpkg does this but my question
> is - isn't it simpler to delete directory in preinst?

There are corner cases where it simply doesn't work as expected (and
some symlinked files are deleted, e.g. #687657).

Regards

David


All times are GMT. The time now is 05:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.