Discussion:
dovecot.conf kills update (conflicting file)
(too old to reply)
David C. Rankin
2010-09-01 12:44:24 UTC
Permalink
Guys,

The dovecot update needs to be fixed. Currently, on upgrade you get:

checking package integrity...
(288/288) checking for file conflicts
[#####################################] 100%
error: failed to commit transaction (conflicting files)
dovecot: /etc/dovecot/dovecot.conf exists in filesystem
Errors occurred, no packages were upgraded.

which is a bit frustrating. I know we talked a little about fixing dovecot (and
other packages that break if upgraded but not restarted) so I don't know if this
is related (I thought the discussion/debate was whether to add a one-liner
advising that a dovecot restart was required), but in any event, related or not,
dovecot should update without failing due to the existing dovecot.conf

Do I open a ticket or is this post enough?

I have asked this question of whether to open a ticket on every bug or whether
little items like this are preferred to be worked from the list w/o a ticket
opened at least 3 times now and I have never received an answer (I apologize if
I have missed it). I want to help Arch the best way I can. If you want bugs
opened on everything, let me know -- I'm happy to open them. If you can work an
issue from the list, then at least let me know "I'll take it from here" so I
know things are not being missed. Thanks.

--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
David C. Rankin
2010-09-01 12:48:11 UTC
Permalink
On 09/01/2010 07:44 AM, David C. Rankin wrote:
> Guys,
>
> The dovecot update needs to be fixed. Currently, on upgrade you get:
>
> checking package integrity...
> (288/288) checking for file conflicts [#####################################] 100%
> error: failed to commit transaction (conflicting files)
> dovecot: /etc/dovecot/dovecot.conf exists in filesystem
> Errors occurred, no packages were upgraded.
>
> which is a bit frustrating. I know we talked a little about fixing dovecot (and
> other packages that break if upgraded but not restarted) so I don't know if this
> is related (I thought the discussion/debate was whether to add a one-liner
> advising that a dovecot restart was required), but in any event, related or not,
> dovecot should update without failing due to the existing dovecot.conf
>
> Do I open a ticket or is this post enough?
>
> I have asked this question of whether to open a ticket on every bug or whether
> little items like this are preferred to be worked from the list w/o a ticket
> opened at least 3 times now and I have never received an answer (I apologize if
> I have missed it). I want to help Arch the best way I can. If you want bugs
> opened on everything, let me know -- I'm happy to open them. If you can work an
> issue from the list, then at least let me know "I'll take it from here" so I
> know things are not being missed. Thanks.
>

I forced the update and:

warning: /etc/dovecot/dovecot.conf installed as /etc/dovecot/dovecot.conf.pacnew
> IMPORTANT DOVECOT 2.0 UPGRADE NOTICE
> ------------------------------------
> see http://wiki2.dovecot.org/Upgrading/2.0
> make sure, you convert the dovecot.conf file
New optional dependencies for dovecot
libmysqlclient: for MySQL back end
postgresql-libs: for Postgres SQl back end
( 8/289) upgrading empathy
[#####################################] 100%
> To use Empathy you need to install at least one Telepathy connection
manager.

Great job on the notice :p


--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
Ng Oon-Ee
2010-09-01 13:59:53 UTC
Permalink
On Wed, 2010-09-01 at 07:44 -0500, David C. Rankin wrote:
<snip>
> but in any event, related or not,
> dovecot should update without failing due to the existing dovecot.conf
<snip>

The dovecot.conf file was created by you previously, hence why the
update is failing. The new dovecot package provides dovecot.conf (I
think because upstream provides it).

Pacman gives an error in situations like this, as it well should, since
I doubt anybody wants their configs wiped out. As such I don't think
this is even a bug.
David C. Rankin
2010-09-01 16:58:58 UTC
Permalink
On 09/01/2010 08:59 AM, Ng Oon-Ee wrote:
> On Wed, 2010-09-01 at 07:44 -0500, David C. Rankin wrote:
> <snip>
>> but in any event, related or not,
>> dovecot should update without failing due to the existing dovecot.conf
> <snip>
>
> The dovecot.conf file was created by you previously, hence why the
> update is failing. The new dovecot package provides dovecot.conf (I
> think because upstream provides it).
>
> Pacman gives an error in situations like this, as it well should, since
> I doubt anybody wants their configs wiped out. As such I don't think
> this is even a bug.
>
>

? Que?

I thought that was what was supposed to be handled by .pacnew and .pacsav. Of
course there will be a dovecot.conf. (dovecot won't work without it) Everybody
knows that. Why should/would an Arch update not be able to handle that simple fact.

You know more than I, but to me, it looks like a bug that Arch needs to be
smart enough to fix. I propose that whoever maintains dovecot for Arch fix the
install to install the new dovecot.conf and dovecot.conf.pacnew. That way we
don't blow up a 288 package update just because the dovecot installer isn't
smart enough to know that if dovecot is already installed -> expect a dovecot.conf.

Do you disagree with that? If so, why?

--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
Ng Oon-Ee
2010-09-01 23:08:08 UTC
Permalink
On Wed, 2010-09-01 at 11:58 -0500, David C. Rankin wrote:
> On 09/01/2010 08:59 AM, Ng Oon-Ee wrote:
> > On Wed, 2010-09-01 at 07:44 -0500, David C. Rankin wrote:
> > <snip>
> >> but in any event, related or not,
> >> dovecot should update without failing due to the existing dovecot.conf
> > <snip>
> >
> > The dovecot.conf file was created by you previously, hence why the
> > update is failing. The new dovecot package provides dovecot.conf (I
> > think because upstream provides it).
> >
> > Pacman gives an error in situations like this, as it well should, since
> > I doubt anybody wants their configs wiped out. As such I don't think
> > this is even a bug.
> >
> >
>
> ? Que?
>
> I thought that was what was supposed to be handled by .pacnew and .pacsav. Of
> course there will be a dovecot.conf. (dovecot won't work without it) Everybody
> knows that. Why should/would an Arch update not be able to handle that simple fact.
>
> You know more than I, but to me, it looks like a bug that Arch needs to be
> smart enough to fix. I propose that whoever maintains dovecot for Arch fix the
> install to install the new dovecot.conf and dovecot.conf.pacnew. That way we
> don't blow up a 288 package update just because the dovecot installer isn't
> smart enough to know that if dovecot is already installed -> expect a dovecot.conf.
>
> Do you disagree with that? If so, why?
>
Files on the filesystem either belong to a package or they don't.
dovecot.conf didn't, because the older dovecot packages (1.2-x) did not
have the /etc/dovecot.conf file. You created that file yourself when you
set dovecot up the first time.

Now, the dovecot 2.0+ packages DO have that file. What else do you want
pacman to do when the following is true:-
1. Package A did not use to own file B.
2. Package A now owns file B.
3. File B already exists on the filesystem.

The file may not be a conf file. It may be a binary, a library etc. It
may not even be intended for package A, but may belong, say, to package
C. In any case, since YOU created it, you're responsible for deciding
what you want to do with it.

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.

Finally, there is no 'dovecot installer'. It is a package, a compressed
collection of files. dovecot.install is mainly for post-install messages
or perhaps some system configuration using common tools. Not to create
configuration files from scratch (that's your job).
David C. Rankin
2010-09-02 04:35:30 UTC
Permalink
On 09/01/2010 06:08 PM, Ng Oon-Ee wrote:
> On Wed, 2010-09-01 at 11:58 -0500, David C. Rankin wrote:
>> On 09/01/2010 08:59 AM, Ng Oon-Ee wrote:
>>> On Wed, 2010-09-01 at 07:44 -0500, David C. Rankin wrote:
>>> <snip>
>>>> but in any event, related or not,
>>>> dovecot should update without failing due to the existing dovecot.conf
>>> <snip>
>>>
>>> The dovecot.conf file was created by you previously, hence why the
>>> update is failing. The new dovecot package provides dovecot.conf (I
>>> think because upstream provides it).
>>>
>>> Pacman gives an error in situations like this, as it well should, since
>>> I doubt anybody wants their configs wiped out. As such I don't think
>>> this is even a bug.
>>>
>>>
>>
>> ? Que?
>>
>> I thought that was what was supposed to be handled by .pacnew and .pacsav. Of
>> course there will be a dovecot.conf. (dovecot won't work without it) Everybody
>> knows that. Why should/would an Arch update not be able to handle that simple fact.
>>
>> You know more than I, but to me, it looks like a bug that Arch needs to be
>> smart enough to fix. I propose that whoever maintains dovecot for Arch fix the
>> install to install the new dovecot.conf and dovecot.conf.pacnew. That way we
>> don't blow up a 288 package update just because the dovecot installer isn't
>> smart enough to know that if dovecot is already installed -> expect a dovecot.conf.
>>
>> Do you disagree with that? If so, why?
>>
> Files on the filesystem either belong to a package or they don't.
> dovecot.conf didn't, because the older dovecot packages (1.2-x) did not
> have the /etc/dovecot.conf file. You created that file yourself when you
> set dovecot up the first time.
>
> Now, the dovecot 2.0+ packages DO have that file. What else do you want
> pacman to do when the following is true:-
> 1. Package A did not use to own file B.
> 2. Package A now owns file B.
> 3. File B already exists on the filesystem.
>
> The file may not be a conf file. It may be a binary, a library etc. It
> may not even be intended for package A, but may belong, say, to package
> C. In any case, since YOU created it, you're responsible for deciding
> what you want to do with it.
>
> 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.
>
> Finally, there is no 'dovecot installer'. It is a package, a compressed
> collection of files. dovecot.install is mainly for post-install messages
> or perhaps some system configuration using common tools. Not to create
> configuration files from scratch (that's your job).
>
>

OK, I'm buying it. What you are telling me is that for 1X there was NO
dovecot.conf (IIRC it was something like dovecot.conf.example because I compared
something to my suse dovecot.conf when I moved to Arch)....AND... you are saying
since 1X didn't have one, the fact that 2.0 does somehow causes the 1.x->2.0
update to evade (or fall outside of) the way the .pacnew logic works because the
2.0 install doesn't know about 1.x having a dovecot.conf??

That just seems wonky. So for httpd, it has a httpd.conf from the first version,
so it doesn't complain when apache is updated or you get a .pacnew.

OK, then, this 1.2-2.0 transition should be the only dovecot update that craters
the update do to the existence of the dovecot.conf file. So when I updae to 2.1,
there should be no update killing complaint about the dovecot.conf.

Right?

Just seems weird that any package with a mandatory config would puke when it
finds the mandatory config from a prior version actually there.

So far this dovecot update, *every* Archer that updates will have the update
fail do to this problem, but the next update to 2.0-X should be fine, right?


--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
Ng Oon-Ee
2010-09-02 05:25:37 UTC
Permalink
On Wed, 2010-09-01 at 23:35 -0500, David C. Rankin wrote:
> On 09/01/2010 06:08 PM, Ng Oon-Ee wrote:
<snip>
>
> OK, I'm buying it. What you are telling me is that for 1X there was NO
> dovecot.conf (IIRC it was something like dovecot.conf.example because I compared
> something to my suse dovecot.conf when I moved to Arch)....AND... you are saying
> since 1X didn't have one, the fact that 2.0 does somehow causes the 1.x->2.0
> update to evade (or fall outside of) the way the .pacnew logic works because the
> 2.0 install doesn't know about 1.x having a dovecot.conf??

Yes, that's what I'm saying.

>
> That just seems wonky. So for httpd, it has a httpd.conf from the first version,
> so it doesn't complain when apache is updated or you get a .pacnew.
>
> OK, then, this 1.2-2.0 transition should be the only dovecot update that craters
> the update do to the existence of the dovecot.conf file. So when I updae to 2.1,
> there should be no update killing complaint about the dovecot.conf.
>
> Right?

Right.
>
> Just seems weird that any package with a mandatory config would puke when it
> finds the mandatory config from a prior version actually there.
>
> So far this dovecot update, *every* Archer that updates will have the update
> fail do to this problem, but the next update to 2.0-X should be fine, right?

You seem to be quite uninformed about what packaging actually is.
Various statements you make about 'dovecot installer' and 'update
killing complaint' indicate this. Packaging is separate from the
application, and the job done by the package management system is
actually very simple at its core (keep track of files belonging to a
package).

Basically, 'installation' means something very different on a Linux
system than on a Windows system (which is where your comments seem
rooted). If you would take some time to try and understand the various
things pacman does, you'd save yourself and others a lot more time on
the various issues you bring to this list.

Cheers,
Ng Oon-Ee
Baho Utot
2010-09-02 09:39:25 UTC
Permalink
On 09/01/2010 07:08 PM, Ng Oon-Ee wrote:
> On Wed, 2010-09-01 at 11:58 -0500, David C. Rankin wrote:
>> On 09/01/2010 08:59 AM, Ng Oon-Ee wrote:
>>> On Wed, 2010-09-01 at 07:44 -0500, David C. Rankin wrote:
>>> <snip>
>>>> but in any event, related or not,
>>>> dovecot should update without failing due to the existing dovecot.conf
>>> <snip>
>>>
>>> The dovecot.conf file was created by you previously, hence why the
>>> update is failing. The new dovecot package provides dovecot.conf (I
>>> think because upstream provides it).
>>>
>>> Pacman gives an error in situations like this, as it well should, since
>>> I doubt anybody wants their configs wiped out. As such I don't think
>>> this is even a bug.
>>>
>>>
>> ? Que?
>>
>> I thought that was what was supposed to be handled by .pacnew and .pacsav. Of
>> course there will be a dovecot.conf. (dovecot won't work without it) Everybody
>> knows that. Why should/would an Arch update not be able to handle that simple fact.
>>
>> You know more than I, but to me, it looks like a bug that Arch needs to be
>> smart enough to fix. I propose that whoever maintains dovecot for Arch fix the
>> install to install the new dovecot.conf and dovecot.conf.pacnew. That way we
>> don't blow up a 288 package update just because the dovecot installer isn't
>> smart enough to know that if dovecot is already installed -> expect a dovecot.conf.
>>
>> Do you disagree with that? If so, why?
>>
> Files on the filesystem either belong to a package or they don't.
> dovecot.conf didn't, because the older dovecot packages (1.2-x) did not
> have the /etc/dovecot.conf file. You created that file yourself when you
> set dovecot up the first time.
>
> Now, the dovecot 2.0+ packages DO have that file. What else do you want
> pacman to do when the following is true:-
> 1. Package A did not use to own file B.
> 2. Package A now owns file B.
> 3. File B already exists on the filesystem.
>
> The file may not be a conf file. It may be a binary, a library etc. It
> may not even be intended for package A, but may belong, say, to package
> C. In any case, since YOU created it, you're responsible for deciding
> what you want to do with it.
>
> 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.
>
> Finally, there is no 'dovecot installer'. It is a package, a compressed
> collection of files. dovecot.install is mainly for post-install messages
> or perhaps some system configuration using common tools. Not to create
> configuration files from scratch (that's your job).
>

The proper thing to do is to rename /etc/dovecot.conf to
dovecot.conf.orginal, do the update and then merge/restore the
dovecot.conf.orginal to/into dovecot.conf.

Then everyone is happy.
Ng Oon-Ee
2010-09-02 10:23:41 UTC
Permalink
On Thu, 2010-09-02 at 05:39 -0400, Baho Utot wrote:
> On 09/01/2010 07:08 PM, Ng Oon-Ee wrote:
> > On Wed, 2010-09-01 at 11:58 -0500, David C. Rankin wrote:
> >> On 09/01/2010 08:59 AM, Ng Oon-Ee wrote:
> >>> On Wed, 2010-09-01 at 07:44 -0500, David C. Rankin wrote:
> >>> <snip>
> >>>> but in any event, related or not,
> >>>> dovecot should update without failing due to the existing dovecot.conf
> >>> <snip>
> >>>
> >>> The dovecot.conf file was created by you previously, hence why the
> >>> update is failing. The new dovecot package provides dovecot.conf (I
> >>> think because upstream provides it).
> >>>
> >>> Pacman gives an error in situations like this, as it well should, since
> >>> I doubt anybody wants their configs wiped out. As such I don't think
> >>> this is even a bug.
> >>>
> >>>
> >> ? Que?
> >>
> >> I thought that was what was supposed to be handled by .pacnew and .pacsav. Of
> >> course there will be a dovecot.conf. (dovecot won't work without it) Everybody
> >> knows that. Why should/would an Arch update not be able to handle that simple fact.
> >>
> >> You know more than I, but to me, it looks like a bug that Arch needs to be
> >> smart enough to fix. I propose that whoever maintains dovecot for Arch fix the
> >> install to install the new dovecot.conf and dovecot.conf.pacnew. That way we
> >> don't blow up a 288 package update just because the dovecot installer isn't
> >> smart enough to know that if dovecot is already installed -> expect a dovecot.conf.
> >>
> >> Do you disagree with that? If so, why?
> >>
> > Files on the filesystem either belong to a package or they don't.
> > dovecot.conf didn't, because the older dovecot packages (1.2-x) did not
> > have the /etc/dovecot.conf file. You created that file yourself when you
> > set dovecot up the first time.
> >
> > Now, the dovecot 2.0+ packages DO have that file. What else do you want
> > pacman to do when the following is true:-
> > 1. Package A did not use to own file B.
> > 2. Package A now owns file B.
> > 3. File B already exists on the filesystem.
> >
> > The file may not be a conf file. It may be a binary, a library etc. It
> > may not even be intended for package A, but may belong, say, to package
> > C. In any case, since YOU created it, you're responsible for deciding
> > what you want to do with it.
> >
> > 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.
> >
> > Finally, there is no 'dovecot installer'. It is a package, a compressed
> > collection of files. dovecot.install is mainly for post-install messages
> > or perhaps some system configuration using common tools. Not to create
> > configuration files from scratch (that's your job).
> >
>
> The proper thing to do is to rename /etc/dovecot.conf to
> dovecot.conf.orginal, do the update and then merge/restore the
> dovecot.conf.orginal to/into dovecot.conf.
>
> Then everyone is happy.
>
Actually, the proper thing to do is stated in the post-install message.
The behaviour you're talking about is not done by pacman, because with
dovecot 1.2 dovecot.conf was not part of the dovecot package, as already
mentioned.
David C. Rankin
2010-09-03 04:02:53 UTC
Permalink
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?

Additionally, there needs to be a 'non-critical' check that is employed for the
times when an already installed font causes the install to fail.

This isn't a giant problem, but it is an annoyance. Over the past 1.5 years on
8-10 Arch boxes, I have run into a dozen issues like this. Some for something as
simple as a specific font already being installed which causes the install to
stop as mentioned above.

I'm not knocking Arch, I'm just trying to explore how much work it would take
to make pacman just a little smarter so it avoids some of these things. That is
what I DON'T know.

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.

If it is too much work from a cost/benefit standpoint, then just throw this in
the "Arch Ideas" files for later or hit 'del'.

--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
Ng Oon-Ee
2010-09-03 06:11:10 UTC
Permalink
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.
David C. Rankin
2010-09-03 07:23:20 UTC
Permalink
On 09/03/2010 01:11 AM, Ng Oon-Ee wrote:
> 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.
>

Cool -- now that's a clean answer. On to the next improvement idea...

--
David C. Rankin, J.D.,P.E.
Rankin Law Firm, PLLC
510 Ochiltree Street
Nacogdoches, Texas 75961
Telephone: (936) 715-9333
Facsimile: (936) 715-9339
www.rankinlawfirm.com
Pierre Chapuis
2010-09-03 14:03:45 UTC
Permalink
On Thu, 02 Sep 2010 23:02:53 -0500, "David C. Rankin"
<***@suddenlinkmail.com> wrote:

> I'm not knocking Arch, I'm just trying to explore how much work it
> would take to make pacman just a little smarter so it avoids some of
> these things. That is what I DON'T know.

The work it would take is not the only problem. I (and probably other
people too) don't want Pacman to be too smart. Because it does only what
it must in a conservative manner, I can understand what it does and fix
my system if needed. For instance, I had the same problem with Dovecot
and I understood immediately what had happened so I changed my
configuration file and it didn't crash on reboot.

The more things a tool does, the more difficult it is to understand.
Aptitude is probably "smarter" than Pacman but I screw my system up a
lot more when I use it on Debian than when I use an Arch box. That's the
advantage of simplicity: as an operations guy I prefer to run several
commands and edit a bunch of configuration files but know perfectly what
I've done than run one command that works 99% of the time but doesn't
give you a chance to fix the system when it screws up.

--
Pierre 'catwell' Chapuis
Continue reading on narkive:
Loading...