Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Mon, Jan 11, 2010 at 11:36:55AM -0500, Eric Bélanger wrote:
On Mon, Jan 11, 2010 at 8:06 AM, Paul Mattal <paul@mattal.com> wrote:
On 01/06/2010 01:09 AM, Paul Mattal wrote: I've just placed dcron 4.2 into [testing]. This is a major update to dcron, under a new maintainer (who is an Arch user, and very responsive). With this release, I am also taking over maintaining dcron in [core].
Why did you put etc/rc.d/crond in the backup array? These daemon scripts are not intended to be modified by the user. If you want them to be able to pass different options, you should use a /etc/conf.d/crond config file.
Hi Eric, I did that in a proposed PKGBUILD I sent to Paul. It'll be up to him how to package this, but this prompts a more general question I have. Granted that daemon scripts are not supposed to be modified by the ordinary user; the /etc/conf.d mechanism is the usual way to supply arguments to the daemon scripts. However, it's one thing to say "not usually supposed to be user-modified" and slightly different to say "overwrites user mods without notice." I find myself tweaking a few /etc/rc.d scripts now and then. I know there's an existing mechanism to protect such changes: NoUpgrade in /etc/pacman.conf. But I wondered why more PKGBUILDs didn't just add the daemons to the backup array. So the question is: should we think of it as _policy_ that rc.d scripts don't go in backup array, and should instead always be explicitly protected by the user if user wants to mod? No problem if so, it's actually helpful to know there's an explicit policy to always do it the one way or always do it the other way. As to dcron 4.2, I've already gotten some feedback. Thanks. I'll release a new version shortly, but do keep feedback coming. -- Jim Pryor profjim@jimpryor.net
On Mon, Jan 11, 2010 at 12:16 PM, Jim Pryor <lists+arch-general@jimpryor.net> wrote:
On Mon, Jan 11, 2010 at 11:36:55AM -0500, Eric Bélanger wrote:
On Mon, Jan 11, 2010 at 8:06 AM, Paul Mattal <paul@mattal.com> wrote:
On 01/06/2010 01:09 AM, Paul Mattal wrote: I've just placed dcron 4.2 into [testing]. This is a major update to dcron, under a new maintainer (who is an Arch user, and very responsive). With this release, I am also taking over maintaining dcron in [core].
Why did you put etc/rc.d/crond in the backup array? These daemon scripts are not intended to be modified by the user. If you want them to be able to pass different options, you should use a /etc/conf.d/crond config file.
Hi Eric, I did that in a proposed PKGBUILD I sent to Paul. It'll be up to him how to package this, but this prompts a more general question I have.
Granted that daemon scripts are not supposed to be modified by the ordinary user; the /etc/conf.d mechanism is the usual way to supply arguments to the daemon scripts.
However, it's one thing to say "not usually supposed to be user-modified" and slightly different to say "overwrites user mods without notice." I find myself tweaking a few /etc/rc.d scripts now and then. I know there's an existing mechanism to protect such changes: NoUpgrade in /etc/pacman.conf. But I wondered why more PKGBUILDs didn't just add the daemons to the backup array.
So the question is: should we think of it as _policy_ that rc.d scripts don't go in backup array, and should instead always be explicitly protected by the user if user wants to mod?
If you modify it, you should add it to the NoUpgrade line in /etc/pacman.conf. The backup array is for what we INTEND to be modified. Users are more than welcome to do what we don't intend, but you need to control whether of not pacman mucks with those files yourself
On Mon, Jan 11, 2010 at 13:38, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
If you modify it, you should add it to the NoUpgrade line in /etc/pacman.conf. The backup array is for what we INTEND to be modified. Users are more than welcome to do what we don't intend, but you need to control whether of not pacman mucks with those files yourself
+1
On Mon 11 Jan 2010 13:54 -0500, Daenyth Blank wrote:
On Mon, Jan 11, 2010 at 13:38, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
If you modify it, you should add it to the NoUpgrade line in /etc/pacman.conf. The backup array is for what we INTEND to be modified. Users are more than welcome to do what we don't intend, but you need to control whether of not pacman mucks with those files yourself
+1
I appreciate that you've added to the discussion. I hope that we may reach a large sum total. +100 Cheers!
Am 11.01.2010 19:38, schrieb Aaron Griffin:
If you modify it, you should add it to the NoUpgrade line in /etc/pacman.conf. The backup array is for what we INTEND to be modified. Users are more than welcome to do what we don't intend, but you need to control whether of not pacman mucks with those files yourself
I would even go further and recommend not to modify the daemon script, but rather create a copy on the filesystem (not tracked by pacman) and use/modify that one.
On Mon, Jan 11, 2010 at 4:38 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 11.01.2010 19:38, schrieb Aaron Griffin:
If you modify it, you should add it to the NoUpgrade line in /etc/pacman.conf. The backup array is for what we INTEND to be modified. Users are more than welcome to do what we don't intend, but you need to control whether of not pacman mucks with those files yourself
I would even go further and recommend not to modify the daemon script, but rather create a copy on the filesystem (not tracked by pacman) and use/modify that one.
We're also going to get a ton of bug reports here if the init script changed- a lot of people will not move the new one in to place, which will never replace the old one because it wasn't tracked before by backup and pacman won't overwrite it automatically. I'd agree with Thomas here- there are multiple ways to avoid getting your local changes overwritten. It might be in /etc/, but this is all but a binary that we (as a distro) happen to maintain, so people should not be regularly changing these scripts. -Dan
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 I'm fairly new to the Arch Linux scene so am still learning a lot about package building and maintenance. Left over from my Slackware days gone by, Iknow well the importance of the rc.d scripts and how they work. For local stuff, there's rc.local and hopefully a package upgrade doesn't clobber that one because one would expect local users to modify that one. However, I can see the point in ensuring the other scripts aren't locally modified without realizing that a package future upgrade will overlay it. If this isn't done already, maybe the alternative configuation methods should be well documented in the wiki or some place detailing the use of /etc/conf.d. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAktL+U0ACgkQWSjv55S0LfHckwCgrAqtTOQ51VOMRJavh2rbh5ck R1YAoKQ1MomlcLQZvvt06momMKSUZkcU =WwLU -----END PGP SIGNATURE-----
On Mon, 11 Jan 2010, Aaron Griffin wrote:
If you modify it, you should add it to the NoUpgrade line in /etc/pacman.conf. The backup array is for what we INTEND to be modified. Users are more than welcome to do what we don't intend, but you need to control whether of not pacman mucks with those files yourself
Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens? And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them. Thanks, Dimitris
On Wed, Jan 13, 2010 at 12:34 AM, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Mon, 11 Jan 2010, Aaron Griffin wrote:
If you modify it, you should add it to the NoUpgrade line in /etc/pacman.conf. The backup array is for what we INTEND to be modified. Users are more than welcome to do what we don't intend, but you need to control whether of not pacman mucks with those files yourself
Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens? And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them.
pacman -Qh -o, --owns <file> query the package that owns <file> -i, --info view package information (-ii for backup files)
Am 13.01.2010 00:34, schrieb Dimitrios Apostolou:
Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens? And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them.
pacman -Qii is your friend.
On Wed, Jan 13, 2010 at 01:34:52AM +0200, Dimitrios Apostolou wrote:
Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens?
pacman -Qo $file will tell you what package installed $file. find /var/abs -type d -name $package will give you the directory containing the PKGBUILD. fgrep /var/abs/path/to/PKGBUILD -e backup= will give you the backup array. If it's not there, it will be overwritten or removed on upgrades.
And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them.
I know, I've been bitten too. I highly recommend setting up a script to backup your /etc directory daily, and keep at least a week or so of rotated backups. If you've got a good backup system, you can just include this in it. If not, you should get one. But you could in the meantime, or additionally, just set up a separate /etc backup. It needn't take up much space. My /etc is 9 M and the total of a week's worth of daily backups and three weeks of weekly backups beyond that is 20 M. Look into rdiff-backup or rsnapshot. -- profjim@jimpryor.net
On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.01.2010 00:34, schrieb Dimitrios Apostolou:
Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens? And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them.
pacman -Qii is your friend.
This. pacman -Qii dcron will show you all the backup files that pacman will take care of.
On Tue, Jan 12, 2010 at 5:47 PM, Jim Pryor <lists+arch-general@jimpryor.net> wrote:
I know, I've been bitten too. I highly recommend setting up a script to backup your /etc directory daily, and keep at least a week or so of rotated backups. If you've got a good backup system, you can just include this in it. If not, you should get one. But you could in the meantime, or additionally, just set up a separate /etc backup. It needn't take up much space. My /etc is 9 M and the total of a week's worth of daily backups and three weeks of weekly backups beyond that is 20 M. Look into rdiff-backup or rsnapshot.
We use this at work: http://joey.kitenet.net/code/etckeeper/
On Tue, Jan 12, 2010 at 05:50:47PM -0600, Aaron Griffin wrote:
On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler <thomas@archlinux.org> wrote:
pacman -Qii is your friend.
This. pacman -Qii dcron will show you all the backup files that pacman will take care of.
Very nice. When did you guys do that? On Tue, Jan 12, 2010 at 05:51:27PM -0600, Aaron Griffin wrote:
We use this at work: http://joey.kitenet.net/code/etckeeper/
Also nice. -- profjim@jimpryor.net
On Tue, Jan 12, 2010 at 6:50 PM, Jim Pryor <lists+arch-general@jimpryor.net> wrote:
On Tue, Jan 12, 2010 at 05:50:47PM -0600, Aaron Griffin wrote:
On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler <thomas@archlinux.org> wrote:
pacman -Qii is your friend.
This. pacman -Qii dcron will show you all the backup files that pacman will take care of.
Very nice. When did you guys do that?
Forever? It is in the initial git import from 2005, which is the beginnings of pacman 3.X: http://projects.archlinux.org/pacman.git/tree/src/pacman/package.c?id=d04ba#... -Dan
On Tue, Jan 12, 2010 at 08:41:47PM -0600, Dan McGee wrote:
Very nice. When did you guys do that?
Forever? It is in the initial git import from 2005, which is the beginnings of pacman 3.X: http://projects.archlinux.org/pacman.git/tree/src/pacman/package.c?id=d04ba#...
Just shows: read a manpage 20 times? look again because you've still missed stuff. Well except a gnu manpage. -- profjim@jimpryor.net
On Tue, Jan 12, 2010 at 8:55 PM, Jim Pryor <lists+arch-general@jimpryor.net> wrote:
On Tue, Jan 12, 2010 at 08:41:47PM -0600, Dan McGee wrote:
Very nice. When did you guys do that?
Forever? It is in the initial git import from 2005, which is the beginnings of pacman 3.X: http://projects.archlinux.org/pacman.git/tree/src/pacman/package.c?id=d04ba#...
Just shows: read a manpage 20 times? look again because you've still missed stuff.
Well except a gnu manpage.
Haha, the documentation didn't come until 2007 however, so you do have a point there. :) -Dan
On Tue, 2010-01-12 at 21:06 -0600, Dan McGee wrote:
On Tue, Jan 12, 2010 at 8:55 PM, Jim Pryor <lists+arch-general@jimpryor.net> wrote:
On Tue, Jan 12, 2010 at 08:41:47PM -0600, Dan McGee wrote:
Very nice. When did you guys do that?
Forever? It is in the initial git import from 2005, which is the beginnings of pacman 3.X: http://projects.archlinux.org/pacman.git/tree/src/pacman/package.c?id=d04ba#...
Just shows: read a manpage 20 times? look again because you've still missed stuff.
Well except a gnu manpage.
Haha, the documentation didn't come until 2007 however, so you do have a point there. :)
-Dan
An undocumented feature? Who'd have thunk it?
On Tue, 12 Jan 2010, Aaron Griffin wrote:
On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.01.2010 00:34, schrieb Dimitrios Apostolou:
Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens? And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them.
pacman -Qii is your friend.
This. pacman -Qii dcron will show you all the backup files that pacman will take care of.
Guys that thing bit me again: During the big libpng upgrade "initscripts" package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten without notifying me. Because of special changes I've made to mount /var as tmpfs, and because I forgot to put the files in the NoUpgrade line of pacman.conf, the system was unbootable and after fixing it pacman wants to download 500MB of packages again (ideas?). :-@ Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN Since this case is extremely rare, the message would appear scarcely. I can't thing of anything negative for such a feature. Dimitris
On Wed, Feb 10, 2010 at 3:30 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
Guys that thing bit me again: During the big libpng upgrade "initscripts" package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten without notifying me. Because of special changes I've made to mount /var as tmpfs, and because I forgot to put the files in the NoUpgrade line of pacman.conf, the system was unbootable and after fixing it pacman wants to download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I can't thing of anything negative for such a feature.
Dimitris
Or simply add rc.sysinit to the backup array in the PKGBUILD. I was bit by this as well, but I had a backup close by. Imagine that. d
On Wed, Feb 10, 2010 at 2:30 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Tue, 12 Jan 2010, Aaron Griffin wrote:
On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.01.2010 00:34, schrieb Dimitrios Apostolou:
Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens? And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them.
pacman -Qii is your friend.
This. pacman -Qii dcron will show you all the backup files that pacman will take care of.
Guys that thing bit me again: During the big libpng upgrade "initscripts" package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten without notifying me. Because of special changes I've made to mount /var as tmpfs, and because I forgot to put the files in the NoUpgrade line of pacman.conf, the system was unbootable and after fixing it pacman wants to download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I can't thing of anything negative for such a feature.
I can: extra work for people who are already taxed. You want it? Submit a patch.
Am Wed, 10 Feb 2010 22:30:52 +0200 (EET) schrieb Dimitrios Apostolou <jimis@gmx.net>:
Guys that thing bit me again: During the big libpng upgrade "initscripts" package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten without notifying me. Because of special changes I've made to mount /var as tmpfs, and because I forgot to put the files in the NoUpgrade line of pacman.conf, the system was unbootable and after fixing it pacman wants to download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I can't thing of anything negative for such a feature.
Just add NoUpgrade = etc/rc.sysinit to /etc/pacman.conf Such a warning is not necessary, because /etc/rc.sysinit is a system script which usually doesn't need to be modified. And people, who modify it should know what they are doing. Greetings, Heiko
On Wed, 10 Feb 2010, dave reisner wrote:
On Wed, Feb 10, 2010 at 3:30 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
Guys that thing bit me again: During the big libpng upgrade "initscripts" package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten without notifying me. Because of special changes I've made to mount /var as tmpfs, and because I forgot to put the files in the NoUpgrade line of pacman.conf, the system was unbootable and after fixing it pacman wants to download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I can't thing of anything negative for such a feature.
Dimitris
Or simply add rc.sysinit to the backup array in the PKGBUILD. I was bit by this as well, but I had a backup close by. Imagine that.
Because of my experience in this area... I also had a backup and that's how I fixed my system. BU* that happened after I realised something got overwritten, that is *after* the reboot, which costed me my pacman db. Can you imagine it? ;-) Dimitris
d
On Wed, 10 Feb 2010, Aaron Griffin wrote:
On Wed, Feb 10, 2010 at 2:30 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Tue, 12 Jan 2010, Aaron Griffin wrote:
On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.01.2010 00:34, schrieb Dimitrios Apostolou:
Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens? And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them.
pacman -Qii is your friend.
This. pacman -Qii dcron will show you all the backup files that pacman will take care of.
Guys that thing bit me again: During the big libpng upgrade "initscripts" package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten without notifying me. Because of special changes I've made to mount /var as tmpfs, and because I forgot to put the files in the NoUpgrade line of pacman.conf, the system was unbootable and after fixing it pacman wants to download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I can't thing of anything negative for such a feature.
I can: extra work for people who are already taxed. You want it? Submit a patch.
OK I like that, from previous answers I thought it was a choice not to fix it. I will try to submit the patch. Dimitris
On 11 February 2010 05:03, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Wed, 10 Feb 2010, Aaron Griffin wrote:
On Wed, Feb 10, 2010 at 2:30 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Tue, 12 Jan 2010, Aaron Griffin wrote:
On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.01.2010 00:34, schrieb Dimitrios Apostolou:
Since I've been bitten by this, how can I know if the file I modified is goint to be overwritten or not, *before* it actually happens? And even if it is, a .pacsave wouldn't hurt anyone, if I remember correctly (it's been some time) I had completely lost my changes, and I had to rewrite them.
pacman -Qii is your friend.
This. pacman -Qii dcron will show you all the backup files that pacman will take care of.
Guys that thing bit me again: During the big libpng upgrade "initscripts" package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten without notifying me. Because of special changes I've made to mount /var as tmpfs, and because I forgot to put the files in the NoUpgrade line of pacman.conf, the system was unbootable and after fixing it pacman wants to download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I can't thing of anything negative for such a feature.
I can: extra work for people who are already taxed. You want it? Submit a patch.
OK I like that, from previous answers I thought it was a choice not to fix it. I will try to submit the patch.
Dimitris
Yep. I got my answer for this a while back when I actually filed a report for it (or a forum post, can't remember). It's a system file, you're _not_ supposed to overwrite it. If you do, it's up to you to take care of upgrades. -- GPG/PGP ID: B42DDCAD
Am 10.02.2010 21:30, schrieb Dimitrios Apostolou:
Guys that thing bit me again: During the big libpng upgrade "initscripts" package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten without notifying me. Because of special changes I've made to mount /var as tmpfs, and because I forgot to put the files in the NoUpgrade line of pacman.conf, the system was unbootable and after fixing it pacman wants to download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I can't thing of anything negative for such a feature.
This will definitely not happen. pacman will only notify you on files that are marked as "backup" in the package and thus listed in pacman -Qii! All other will be overwritten without a warning (pacman doesn't know you modified them). rc.{sysinit,shutdown} are not supposed to be modified by the user - if you still want to do that, the NoUpgrade feature of pacman will do the job, but then you are completely on your own (Arch gives you all freedom you want, as long as you know you and only you are to blame for problems)! You should try to make your changes work inside Arch: 1) If your changes are general enough to make it into the mainstream initscripts as a feature (or an optional one), submit a feature request with a patch against latest git. 2) If your changes are for local usage only, try to integrate them with the new initscripts hooks system. You can also request to add more hooks to be added in initscripts, just open a feature request. The hooks system is explained in the comments in /etc/rc.d/functions.
On Wed, 10 Feb 2010, Thomas Bächler wrote:
Am 10.02.2010 21:30, schrieb Dimitrios Apostolou:
Guys that thing bit me again: During the big libpng upgrade "initscripts" package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten without notifying me. Because of special changes I've made to mount /var as tmpfs, and because I forgot to put the files in the NoUpgrade line of pacman.conf, the system was unbootable and after fixing it pacman wants to download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I can't thing of anything negative for such a feature.
This will definitely not happen. pacman will only notify you on files that are marked as "backup" in the package and thus listed in pacman -Qii! All other will be overwritten without a warning (pacman doesn't know you modified them). rc.{sysinit,shutdown} are not supposed to be
Thanks for the info, so it's not a matter of policy but I now see it's technically not feasible... I wish this was mentioned before. I now noticed that pacman stores the checksums of files in the %PACMAN% array inside "files" file. I somehow was under the impression that no checksums were needed, only the timestams inside the installation tarball.
modified by the user - if you still want to do that, the NoUpgrade feature of pacman will do the job, but then you are completely on your own (Arch gives you all freedom you want, as long as you know you and only you are to blame for problems)!
You should try to make your changes work inside Arch: 1) If your changes are general enough to make it into the mainstream initscripts as a feature (or an optional one), submit a feature request with a patch against latest git. 2) If your changes are for local usage only, try to integrate them with the new initscripts hooks system. You can also request to add more hooks to be added in initscripts, just open a feature request. The hooks system is explained in the comments in /etc/rc.d/functions.
My patch is only 3 lines before any other initialisation has taken place, and copies /var from disk to tmpfs. I'm using it on my Eee 901 for over one year, but it's really custom and non-portable. I didn't know about the new hooks system, I think I like it. When I find some time to port my 3-lines patch to it, I'll post it here in case someone else needs it. Dimitris
On Thu, Feb 11, 2010 at 11:26 AM, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Wed, 10 Feb 2010, Thomas Bächler wrote:
Am 10.02.2010 21:30, schrieb Dimitrios Apostolou:
Guys that thing bit me again: During the big libpng upgrade "initscripts" package got upgraded too and /etc/rc.{sysinit,shutdown} got overwritten without notifying me. Because of special changes I've made to mount /var as tmpfs, and because I forgot to put the files in the NoUpgrade line of pacman.conf, the system was unbootable and after fixing it pacman wants to download 500MB of packages again (ideas?). :-@
Can't pacman just emit a big fat warning like: WARNING: /etc/rc.sysinit USER CHANGES OVERWRITTEN
Since this case is extremely rare, the message would appear scarcely. I can't thing of anything negative for such a feature.
This will definitely not happen. pacman will only notify you on files that are marked as "backup" in the package and thus listed in pacman -Qii! All other will be overwritten without a warning (pacman doesn't know you modified them). rc.{sysinit,shutdown} are not supposed to be
Thanks for the info, so it's not a matter of policy but I now see it's technically not feasible... I wish this was mentioned before. I now noticed that pacman stores the checksums of files in the %PACMAN% array inside "files" file. I somehow was under the impression that no checksums were needed, only the timestams inside the installation tarball.
modified by the user - if you still want to do that, the NoUpgrade feature of pacman will do the job, but then you are completely on your own (Arch gives you all freedom you want, as long as you know you and only you are to blame for problems)!
You should try to make your changes work inside Arch: 1) If your changes are general enough to make it into the mainstream initscripts as a feature (or an optional one), submit a feature request with a patch against latest git. 2) If your changes are for local usage only, try to integrate them with the new initscripts hooks system. You can also request to add more hooks to be added in initscripts, just open a feature request. The hooks system is explained in the comments in /etc/rc.d/functions.
My patch is only 3 lines before any other initialisation has taken place, and copies /var from disk to tmpfs. I'm using it on my Eee 901 for over one year, but it's really custom and non-portable. I didn't know about the new hooks system, I think I like it. When I find some time to port my 3-lines patch to it, I'll post it here in case someone else needs it.
I'm sure, using the hooks system, you can add a very early hook that just mounts /var on tmpfs. Problem solved :)
participants (13)
-
Aaron Griffin
-
Daenyth Blank
-
Dan McGee
-
dave reisner
-
Dimitrios Apostolou
-
Heiko Baums
-
Jim Pryor
-
Loui Chang
-
Ng Oon-Ee
-
Ray Rashif
-
Steve Holmes
-
Thomas Bächler
-
Xavier