Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Tue, 2010-01-12 at 21:06 -0600, Dan McGee wrote: > On Tue, Jan 12, 2010 at 8:55 PM, Jim Pryor > 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#n85 > > > > 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?
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Tue, Jan 12, 2010 at 8:55 PM, Jim Pryor 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#n85 > > 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
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
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#n85 Just shows: read a manpage 20 times? look again because you've still missed stuff. Well except a gnu manpage. -- prof...@jimpryor.net
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Tue, Jan 12, 2010 at 6:50 PM, Jim Pryor 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 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#n85 -Dan
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
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 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. -- prof...@jimpryor.net
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Tue, Jan 12, 2010 at 5:47 PM, Jim Pryor 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/
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Tue, Jan 12, 2010 at 5:43 PM, Thomas Bächler 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.
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
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. -- prof...@jimpryor.net
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Wed, Jan 13, 2010 at 12:34 AM, Dimitrios Apostolou 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 query the package that owns -i, --info view package information (-ii for backup files)
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
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
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
-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-
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Mon, Jan 11, 2010 at 4:38 PM, Thomas Bächler 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
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
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. signature.asc Description: OpenPGP digital signature
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Mon 11 Jan 2010 13:54 -0500, Daenyth Blank wrote: > On Mon, Jan 11, 2010 at 13:38, 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 > > +1 I appreciate that you've added to the discussion. I hope that we may reach a large sum total. +100 Cheers!
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Mon, Jan 11, 2010 at 13:38, 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 > +1
Re: [arch-general] [arch-dev-public] [signoff] dcron 4.2
On Mon, Jan 11, 2010 at 12:16 PM, Jim Pryor 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 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
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 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 prof...@jimpryor.net
