Re: rm -rf /usr/somedir in maintainer scripts? (was: dpkg, symlinks, directories)
also sprach Nikolaus Rath [2012.09.30.0056 +0200]: > > 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. > > Somehow that sounds like a really bad idea to me. Admittedly > manually placing some file in /usr/include/libfm is pretty ugly, > but I would still certainly not expect that upgrading the libfm > package would remove it. Do not mess with /usr, that is exclusively the domain of dpkg. Any file you place there may well be overridden. Use dpkg-divert if you have to. -- .''`. martin f. krafft Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems "a warm bed in a house sounds a mite better than eating a hot dog on a stick with an old geezer traveling on a lawn mower." -- alvin straight (the straight story) digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: rm -rf /usr/somedir in maintainer scripts?
On Sat, 29 Sep 2012 20:29:09 -0400, Nikolaus Rath wrote: > 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. > >>>Somehow that sounds like a really bad idea to me. Admittedly manually > >>>placing some file in /usr/include/libfm is pretty ugly, but I would > >>>still certainly not expect that upgrading the libfm package would remove > >>>it. > >>>Is that really good practice? Can packages "own" a directory, so that > >>>anything that the local admin puts there may be removed automatically? Yes, there's no guarantee that a directory belonging to a package will be there after the next upgrade. > No, I'm afraid I don't have any good suggestion for the problem at hand. > I'm writing this mostly as a user who gets really concerned when he reads > rm -rf. On my laptop: % grep 'rm -rf' /var/lib/dpkg/info/* | wc -l 183 Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- NP: Funny van Dannen: 1000 Dinge signature.asc Description: Digital signature
Re: rm -rf /usr/somedir in maintainer scripts?
"Andrej N. Gritsenko" writes: > Hello! > > I have written on Sunday, 30 September, at 2:12: >>Nikolaus Rath has written on Saturday, 29 September, at 18:56: >>>"Andrej N. Gritsenko" writes: 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. > >>>Somehow that sounds like a really bad idea to me. Admittedly manually >>>placing some file in /usr/include/libfm is pretty ugly, but I would >>>still certainly not expect that upgrading the libfm package would remove >>>it. > >>>Is that really good practice? Can packages "own" a directory, so that >>>anything that the local admin puts there may be removed automatically? > >>Probably I'm wrong in that. Do you think preinst script should fail >>instead if target-to-replace directory is not empty? > > And that will not work certainly. If package is being upgraded then old > files will be still in place so rmdir will fail in any case. > > Could you propose any better way to do then? Postinst script which does > rmdir and makes symlink instead of not-installed from package? Isn't it > dirty somehow? No, I'm afraid I don't have any good suggestion for the problem at hand. I'm writing this mostly as a user who gets really concerned when he reads rm -rf. Sorry... -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3145p62@vostro.rath.org
Re: rm -rf /usr/somedir in maintainer scripts? (was: dpkg, symlinks, directories)
Hello! I have written on Sunday, 30 September, at 2:12: >Nikolaus Rath has written on Saturday, 29 September, at 18:56: >>"Andrej N. Gritsenko" writes: >>> 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. >>Somehow that sounds like a really bad idea to me. Admittedly manually >>placing some file in /usr/include/libfm is pretty ugly, but I would >>still certainly not expect that upgrading the libfm package would remove >>it. >>Is that really good practice? Can packages "own" a directory, so that >>anything that the local admin puts there may be removed automatically? >Probably I'm wrong in that. Do you think preinst script should fail >instead if target-to-replace directory is not empty? And that will not work certainly. If package is being upgraded then old files will be still in place so rmdir will fail in any case. Could you propose any better way to do then? Postinst script which does rmdir and makes symlink instead of not-installed from package? Isn't it dirty somehow? Andriy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929232630.gc26...@rep.kiev.ua
Re: rm -rf /usr/somedir in maintainer scripts? (was: dpkg, symlinks, directories)
Hello! Nikolaus Rath has written on Saturday, 29 September, at 18:56: >"Andrej N. Gritsenko" writes: >> 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. >Somehow that sounds like a really bad idea to me. Admittedly manually >placing some file in /usr/include/libfm is pretty ugly, but I would >still certainly not expect that upgrading the libfm package would remove >it. >Is that really good practice? Can packages "own" a directory, so that >anything that the local admin puts there may be removed automatically? Probably I'm wrong in that. Do you think preinst script should fail instead if target-to-replace directory is not empty? Andriy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929231253.gb26...@rep.kiev.ua
rm -rf /usr/somedir in maintainer scripts? (was: dpkg, symlinks, directories)
"Andrej N. Gritsenko" writes: > 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. Somehow that sounds like a really bad idea to me. Admittedly manually placing some file in /usr/include/libfm is pretty ugly, but I would still certainly not expect that upgrading the libfm package would remove it. Is that really good practice? Can packages "own" a directory, so that anything that the local admin puts there may be removed automatically? Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fw605th5.fsf...@vostro.rath.org
Re: Debian not suitable for SSD due to apt/dpkg?
On Sat, Sep 29, 2012 at 10:26:57PM +0200, Frank Bauer wrote: > I am considering migrating my Debian testing system to a SSD to speed things > up. > Since SSD lifetime is severely limited (about 5000 overwrites for > consumer grade MLC), I wanted to know beforehand, how much writes does > my system generate. If you have 5000 erase cycles, it will run for 13 years if you overwrite it once per day. Do you really expect this device to work until this? > iostat (part of sysstat) revealed, that simple apt-get update command > generated about 250MB of writes! How does it reveal this? > We are talking about current debian testing on ext4 filesystem with > noatime option enabled. You also need discard. > Daily apt-get update && apt-get upgrade consumes about 1.2GB of writes > (downloaded size is usually <100MB) Disable pdiffs, mount /var/cache/apt as tmpfs, so at least the packages are not written again. > Do you have similar experience? Isn't that a bit excessive? Can it be avoided? No idea, it is irrelevant. No. Partially. Bastian -- Ahead warp factor one, Mr. Sulu. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929211544.gb17...@wavehammer.waldi.eu.org
Re: Audit of Debian/Ubuntu for unfixed vulnerabilities because of embedded code copies
[Henri Salo] > Has there been any progress with this project? I am glad to help if > there is something I can do? This is needed in my opinion. You could try to run the scripts I created in the debian-security svn repository, and see how they could be improved. I have not had time to work much on this issue for a long time, and this is unlikely to change any time soon. :( You can try to add CPE info to a few packages to test the proposal, and see if it make tracking easier. But first and foremost, you can try to figure out what need to be done to move the idea forward, as I lack the time to do so myself. :( If you want more direct feedback from me, we could meet on IRC to exchange knowledge. Otherwise, you can ask using email. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929203142.gf20...@ulrik.uio.no
Re: Debian not suitable for SSD due to apt/dpkg?
On Sat, 29 Sep 2012 22:26:57 +0200, Frank Bauer wrote: > Hi, Hello, > I am considering migrating my Debian testing system to a SSD to speed things > up. Since SSD lifetime is severely limited (about 5000 overwrites for > consumer grade MLC), I wanted to know beforehand, how much writes does > my system generate. > [..] Have a look at http://wiki.debian.org/SSDoptimization . David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: Audit of Debian/Ubuntu for unfixed vulnerabilities because of embedded code copies
On Mon, Jul 02, 2012 at 07:59:26PM +0200, Petter Reinholdtsen wrote: > [Silvio Cesare] > > I recently ran the tool and cross referenced identified code copies with > > Debian's security tracking of affected packages by CVE. I did this for all > > CVEs in 2010, 2011, and 2012. > > This sound like a job that could become a bit easier if we tagged > Debian packages with the CPE ids assosiated with CVEs, to make it > easier to figure out which Debian package are affected by a given CVE. > > Are you aware of my proposal to do this, mentioned on debian-security > and also drafted on http://wiki.debian.org/CPEtagPackagesDep >? > -- > Happy hacking > Petter Reinholdtsen Has there been any progress with this project? I am glad to help if there is something I can do? This is needed in my opinion. - Henri Salo -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929202243.ga12...@kludge.henri.nerv.fi
Re: CIA going down: KGB wants your commits!
Le vendredi 28 septembre 2012 à 07:49 +0200, Tollef Fog Heen a écrit : > > You can either run your own bot (debian package kgb-bot), or use ours. As > > for the client, alioth does not have it installed, but you can run it off > > /home/groups/kgb. > > It's installed now. Thanks to everyone involved for being so helpful. This was an easy migration and the functionality is back. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1348949622.13271.23.camel@tomoyo
Re: Processor microcode update packages
On Sat, 29 Sep 2012, Eric Valette wrote: > On 29/09/2012 12:32, Henrique de Moraes Holschuh wrote: > >If you want to use non-modular, built-in microcode, the documentation of > >iucode-tool does explain how to trigger the microcode reload after boot. You > >will have to add it to your system yourself. > > Fair enough. Already done. However, during the stable->wheezy > migration, all users building their own kernel may be affected as > microcode.ctl package did had an initscript... And it was properly documented on NEWS.Debian. I expect that, out of the 1400 or so users of Squeeze intel-microcode/microcode.ctl, no more than 1% have custom, no-initramfs kernels with microcode built-in instead of as a module. If you want an initscript, you're welcome to write one and submit it as a patch. I will add it as an example to the package, so that others can easily use it if they want. For this class of user, it will be irrelevant soon enough when a proper way to load microcode updates during initial processor setup lands on v3.7, and we switch to initramfs-piggyback-cpio- assisted microcode updates. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929195631.ga8...@khazad-dum.debian.net
Bug#689163: ITP: edtsurf -- triangulated mesh surfaces for protein structures
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: edtsurf * URL : http://zhanglab.ccmb.med.umich.edu/EDTSurf/ * License : custom, DFSG-free Programming Lang: C++ Description : triangulated mesh surfaces for protein structures EDTSurf is a open source program to construct triangulated surfaces for macromolecules. It generates three major macromolecular surfaces: van der Waals surface, solvent-accessible surface and molecular surface (solvent-excluded surface). EDTsurf also identifies cavities which are inside of macromolecules. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929171319.11730.95087.reportbug@Toshiba.siemens
Re: dpkg, symlinks, directories
On Sat, Sep 29, 2012 at 05:31:40PM +0200, Vincent Bernat wrote: > 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. :( If there are unowned or otherwise problematic files or directories, just abort. Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929163506.ga17...@wavehammer.waldi.eu.org
Re: 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 signature.asc Description: OpenPGP digital signature
Re: dpkg, symlinks, directories
Hello! Vincent Bernat has written on Saturday, 29 September, at 17:31: > ❦ 29 septembre 2012 17:17 CEST, "Andrej N. Gritsenko" : >>>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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929155647.gc30...@rep.kiev.ua
Re: dpkg, symlinks, directories
❦ 29 septembre 2012 13:01 CEST, Andreas Beckmann : >> 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 pgpMpCyY6qVpN.pgp Description: PGP signature
Re: dpkg, symlinks, directories
❦ 29 septembre 2012 17:17 CEST, "Andrej N. Gritsenko" : >>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) pgp2PfOtKgSvw.pgp Description: PGP signature
Re: 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929151722.gb30...@rep.kiev.ua
Re: Processor microcode update packages
On 29/09/2012 12:32, Henrique de Moraes Holschuh wrote: If you want to use non-modular, built-in microcode, the documentation of iucode-tool does explain how to trigger the microcode reload after boot. You will have to add it to your system yourself. Fair enough. Already done. However, during the stable->wheezy migration, all users building their own kernel may be affected as microcode.ctl package did had an initscript... --eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5066d79c.7090...@free.fr
Re: dpkg, symlinks, directories
On 2012-09-29 12:47, Vincent Bernat wrote: > ❦ 29 septembre 2012 12:35 CEST, Salvatore Bonaccorso : > >>> 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-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5066d4fd.8000...@abeckmann.de
Re: dpkg, symlinks, directories
❦ 29 septembre 2012 12:35 CEST, Salvatore Bonaccorso : >> 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 pgpR5GeefebkJ.pgp Description: PGP signature
Re: dpkg, symlinks, directories
❦ 29 septembre 2012 11:59 CEST, Vincent Bernat :
> 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
pgpQcCEBy3GYc.pgp
Description: PGP signature
Re: 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 signature.asc Description: Digital signature
Re: Processor microcode update packages
On Sat, 29 Sep 2012, Eric Valette wrote: > On 29/09/2012 03:46, Henrique de Moraes Holschuh wrote: > >1. No html, please. > > > >non-initrd is supported. Read the package documentation for the details. > > I did. I do not want to compile microcode tool as a module because Currently using microcode as a module is indeed the best choice, as it covers all reasonably common user cases and works right for all supported Linux kernel versions. If you want to use non-modular, built-in microcode, the documentation of iucode-tool does explain how to trigger the microcode reload after boot. You will have to add it to your system yourself. Feel free to write a new initscript and propose it as a wishlist bug to be added to /usr/share/doc/.../examples. If you do, I will add it at the next upload. > So it does not work for people compiling their own kernel and not > using modules (when you tailor your kernel for a given machine, > modules are just slowing the boot process and do not bring > anything). It does not work out-of-the-box. Which is fine as far as I am concerned, you did not get a custom kernel without initramfs support out-of-the-box either. And that happens to be the _only_ setup which is not supported out-of-the-box. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120929103227.ga14...@khazad-dum.debian.net
Re: [OT] kernel modules
Unless under very specific circumstances, the use of a modular kernel brings one the ability to replace the particular hardware the system runs on at will. If I do taylor my kernel for my machine, I do not care at all Say, it's possible to replace a just burned motherboard with an Intel CPU with a different one having an AMD CPU instead. Or one may take the HDD holding the system and put it into a wholly different box, while often retaining the ability to boot. Not true in general unless you compile the whole modules set which takes ages. You probably never rebuild the stock debian kernel on a old machine ;-) For these reasons, in the majority of cases, compiling a non-modular kernel doesn't worth the effort, and may also be harmful to the system's operation. Well I do this happily since 96. Almost never used the debian kernel more than a few days after install. Crashed a lot of disks, replaced mother boards, changed computers... Nothing that booting knoppix iso cannot fix and a lot of time gained each boot and when compiling a new kernel version... -- eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5066c93c.2070...@free.fr
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) pgpWxRCpeNTov.pgp Description: PGP signature
[OT] kernel modules
> Eric Valette writes: […] > I do not want to compile microcode tool as a module because module > loading juts slows down the boot process and contrarilly to many > other package requiring firmware, this one does not enable to load > firmware when not compiled as a module. > So it does not work for people compiling their own kernel and not > using modules (when you tailor your kernel for a given machine, > modules are just slowing the boot process and do not bring anything). Unless under very specific circumstances, the use of a modular kernel brings one the ability to replace the particular hardware the system runs on at will. Say, it's possible to replace a just burned motherboard with an Intel CPU with a different one having an AMD CPU instead. Or one may take the HDD holding the system and put it into a wholly different box, while often retaining the ability to boot. For these reasons, in the majority of cases, compiling a non-modular kernel doesn't worth the effort, and may also be harmful to the system's operation. -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/86txuhqk91.fsf...@gray.siamics.net
Re: Processor microcode update packages
On 29/09/2012 03:46, Henrique de Moraes Holschuh wrote: 1. No html, please. non-initrd is supported. Read the package documentation for the details. I did. I do not want to compile microcode tool as a module because module loading juts slows down the boot process and contrarilly to many other package requiring firmware, this one does not enable to load firmware when not compiled as a module. So it does not work for people compiling their own kernel and not using modules (when you tailor your kernel for a given machine, modules are just slowing the boot process and do not bring anything). -- eric -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5066b198.9030...@free.fr
