[arch-general] dovecot.conf kills update (conflicting file)

[Ng Oon-Ee]

On Thu, 2010-09-02 at 23:02 -0500, David C. Rankin wrote:
> On 09/01/2010 06:08 PM, Ng Oon-Ee wrote:
> > Pacman helps you manage your system, it doesn't (and shouldn't) try to
> > make assumptions about stuff like this, because that's your job. You
> > know your system better than anyone else (ideally).
> >
> > And your assertion about 'blowing up a 288 package update' is nonsense,
> > by the time you reach this error the downloads are done (so they don't
> > have to be repeated) and no files have actually yet been installed.
> > Re-run pacman -Su after fixing the problem and everything just installs
> > as it should have.
> 
> OK,
> 
> 	Now let's turn this conversation around and see if we can't make Arch better. I 
> agree with all you said, and yes, I understand the 'packaging' and installer 
> separation and what pacman does/doesn't do. What I want to explore is what 
> additional effort would it take to identify and make the packaging process (for 
> core server apps especially - mail/apache/etc.) more robust so that pacman can 
> be made 'aware' of mandatory config files that should be expected?

That's the thing, pacman IS aware of it (post dovecot 2). What you're
requesting, if I read correctly, is some sort of 'intelligent input'
that 'package A tends to need config file B, and font C, D, E, even
though they're not in the package at this point they may be in the
future'.

<snip>
> 
> 	The way I look at it is if Arch is going to keep moving forward, kicking ass 
> and gaining market share the way it has in the past, then these are some of the 
> things I notice that, if fixed, will add some of the required 'polish' to Arch 
> to allow it to continue do so. Nothing more, nothing less.

I very much doubt 'moving forward, kicking ass, and gaining market
share' is on the to-do list of any of the devs. There's a whole
different mindset here, chasing a larger user count is not the purpose.

That being said, it would probably be possible to implement something
like what you seem to be suggesting. I doubt it ever will though,
because this IS very much a corner case.