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.
