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.