[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PW#5-3: How packages can register cron jobs



> > > > The current policy does not allow packages to touch /etc/crontab
> > > > anymore. This is because we don't allow packages to modify other
> > > > packages configuration files.
> > >
> > > We should also correct the policy to say that _no_ package should touch
> > > _any_ config file from a script. The problem caused that way isn't related
> > > to which package script and config file belong to.
> >
> > While a good general rule, I think it would be a mistake to make it all
> > encompasing.  There will be cases where touching the conffile within the
> > postinst of another package really will be the best way to do things.
> 
> Well, it might be a way to deal with some brokenness, just like doing
> things like the tetex install checking for other packages because dpkg
> can't do it, even if it ought to.
> 
> But that's for what I'd call "emergencies". Normal use, IMNSHO, must
> _never_ do that.

Why not?  In some cases it makes sense.  For example, the "spamfilter"
package I've uploaded makes use of "spamdb".  Spamdb sends error mail
every week unless it has had a converter specified.  Since when using
"spamfilter" it isn't necessary to have a converter, this error is pointless.
So, the "spamfilter" package sets the convert (if not already set) in the
config file so this error-mail doesn't happen.

Yes, it would be possible to ask the user to make the change, but that would
go against the basic idea of automatic package installation.  Yes, it
would be possible to change spamdb to use some other method, but what
would that accomplish?


> Getting asked what to do about a conffile that you never heard about
> during an upgrade is bad, bad, bad. And that's exactly what will happen if
> you do this.

Yes it is.  There really needs to be general registry of information that
_can_ be changed by anything.  What happened to that project, anyway?


> It's what _does_ happen far too often today.

Agreed.  But until a better solution is implemented, let's avoid making
unnecessary work for ourselves.

By the way...  Did you use to work with OS-9?

                                          Brian
                                 ( bcwhite@verisim.com )

-------------------------------------------------------------------------------
 The squeaky wheel doesn't always get the grease.  Sometimes it gets replaced.


Reply to: