Bug 194246

This conflict is hardly solvable as you don't have to install authconfig for
minimum installation (kickstart driven) and still expect pam (login, sshd) to
work. The authconfig shouldn't be a required package. But on the other hand
authconfig must be able to modify that file. Probably rpm shouldn't make rpmnew
files in case the original and updated package files are the same.

rpm makes .rpmnew problems at the request of the packager, not otherwise.

So this is a packaging problem.

Well, Jeff, the system-auth file must be marked as %config(noreplace) in the pam
package because it is a configuration file which we don't want to overwrite if
it was modified.

The only other way would be to mark the file as a ghost and create it manually
in %post. But this is even more ugly.

I'd say wontfix then as it is a purely cosmetic issue.

How on earth can you consider the contents of /etc/pam.d/system-auth a 
"cosmetic" issue?? What is a end user supposed to do to resolve the conflict? 
The system-auth-ac produced by authconfig during firstboot is now different 
than that provided by updates to pam. Which component is the primary owner of 
the /etc/pam.d/system-auth? pam or authconfig??

I'm reopening this bug and changing the component to pam. Perhaps doing so 
will result in a better evaluation, I hope.

But it was always the case that the system-auth-ac (system-auth directly in
previous Fedora Core releases) created/written by authconfig were conflicting
with the default in the pam package.

The only difference from the previous situation is that the system-auth was
written to directly and rpm doesn't create .rpmnew files when the contents of
the file in the old and new package is the same and the file on disk is a
regular file.

Now the file on disk is a symlink and rpm incorrectly creates .rpmnew file
although the file in old and new package doesn't differ.

On the pam side I can see only one possible workaround, document the situation
in a comment in the system-auth file.

OK, so in the past there was only /etc/pam.d/system-auth, which was 
merged/written by upgrades of pam or invocations of authconfig, both of which 
considered the current contents of the file during the update. Not perfect, 
but at least it was consistent. Now it's not. This was due to your fix for
165342, which  points out that authconfig wasn't preserving/considering 
changes made by users, and maybe not updates to pam's version of the file 
either.

Wouldn't it have been a better to fix 165342 by making authconfig 
understand/preserve the user's changes rather than produce a parallel, manual 
system of update (system-auth-local), which because of the symbolic link, 
would still produce a rpmnew file when pam is updated? If making authconfig 
smarter would make it too unwieldy, than what about making authconfig only 
smart enough to recognize when the user has made manual changes to it that it 
doesn't understand, and simply fail/exit, with a message or dialog saying the 
file needs to be managed manually? Just a thought.

Meanwhile, should I just accept the system-auth provided in the latest pam 
update (system-auth.rpmnew -> system-auth-ac), keep the one authconfig 
created, or move system-auth.rpmnew to system-auth-ac, and rerun authconfig?

Thanks.

Authconfig simply cannot understand the user's changes because it cannot know
the intent of the user when he modified the system-auth file. Also how would
authconfig detect that user modified the file and so he doesn't want to change
it when authconfig is run? It could add a marker in the file which the user
would have to remove if he modified the file however it would effectively
disable the ability to configure authentication with authconfig.

My solution is not perfect however it enables user modifications (although only
limited) of the system-auth configuration and still allows using authconfig for
the main authentication configuration.

If rpm worked as it should this would be a non-issue.

You should of course keep the authconfig generated file and this is a logical
thing as by running authconfig (which is indicated by the symlink) you
effectively say that that the default config in the pam package shouldn't be used.

Also note that this sentence is wrong: "OK, so in the past there was only
/etc/pam.d/system-auth, which was merged/written by upgrades of pam or
invocations of authconfig, both of which considered the current contents of the
file during the update."

On upgrades of pam iff the contents of /etc/pam.d/system-auth in the package
changed there would have been the .rpmnew file created as well, no merge would
have been done. However the contents of /etc/pam.d/system-auth in the pam
package did not change for a very long time.

Created attachment 130962 [details]
Proposed patch to rpm

This is a proposed patch to rpm which should modify its behaviour according to
my proposal. No .rpmnew file should be created if the db and new package files
don't differ regardless of the type of the file on disk.

There are 3 comparisons involved in dbWhat:
   1) the current file on disk
   2) the old file that was originally installed
   3) the new file that is about to be installed.

The current behavior of %config(noreplace) creates a .rpmnew
file iff the current file has been changed wrto what was originally
installed.

You propose changing this behavior to a comparison between old and new,
not creating .rpmnew if old and new are identical, ignoring the file on disk.

This can/will clobber user changed files, which is unacceptable.

Otherwise the patch looks ok.

This is a complete nonsense.

Read the patch properly Jeff. The current behavior of %config(noreplace) creates
a .rpmnewfile iff the type of the current file has been changed wrto what was
originally installed.

The patch changes this behavior so when old and new (in db and in package) is
identical -> not changed, the function returns FA_SKIP -> it won't clobber
anything, it simply skips installation of the file from the package.

Sorry I missed FA_SKIP rather than FA_CREATE.

No matter what, packaging that relies on a change in rpm behavior is doomed to failure,
there is no means to do a universal upgrade of rpm. And that leads to support problem for rpm
because of the changed behavior.

The better fix -- in packaging alone -- is to isolate the file in a single package. This can be done
by having one or the other of the two pkgs install the file, or it can be done by creating a new
package that contains the file.

The current state is nothing fatal or critical and it can stay as it is. So the
packaging doesn't really rely on change in rpm behavior. However it would be
just nice and logical if rpm did what I suggest in the patch.

Created attachment 147986 [details]
Improved patch

This patch handles also the opposite case when old and new packages contain
%config symlink and we have regular file on disk.

Heh, that's the problem with messing with *.{rpmnew,rpmorig,rpmold} creation, there's
always another oddball corener case.

FWIW, the default one-size-fits-all implementation for file resolutions in rpm is never ever gonna
satisfy everyone, and continual adjustments to  Get It Right! are going to lead to
different behaviors between versions that are almost certainly going to make the
algorithm untrustworthy and unreliable.

Lemme see if I can merge your patch into 4.8.8 with some configuration changes to
control through configuration the elements that go into deciding "changed" (i.e. mtime
is one of the elements that noone is expecting as part of "changed") .

This is the patch that I included in rpm-4.4.8-1

mtime parameterizatrion when I get a chance.

(I swear I responded to this bug once before, but perhaps I forgot "Save Changes")

Meanwhile, what do I, as unsuspecting F7 user, do with the newly created
/etc/pam.d/authconfig.rpmnew, which I got as part of the set of updates
installed *just* after installing a fresh F7?

Do note that these files differ (a lot!)

Installed versions of related packages:

authconfig-5.3.13-4.fc7
pam-0.99.7.1-5.1.fc7
rpm-4.4.2-46.fc7

So which one of the system-auth-* is correct, how do I put it in place, and why
do I have to mess with system authentication stuff by hand after updates?

You simply shouldn't do anything (eventually you can remove the .rpmnew file).

Actually you need to merge the .rpmnew into your existing file, not remove it.

That can be done in a number of ways. If changes are large, save the existing file,
and replace with the .rpmnew file. Then find what local modifications you have made
(the reason for the .rpmnew file) and merge the changes into the new version of the file.

No, in comment 18 I was talking about this concrete example of
/etc/pam.d/system-auth.rpmnew. This file is being created just because it must
be  in pam package for small systems where authconfig is not used/installed but
otherwise it is manipulated by authconfig so it has to take it over and the
.rpmnew files which are created by pam upgrades are irrelevant.

Of course for other .rpmnew files comment 19 is correct.

Panu, I saw you included the patch for multilib config conflicts. Could you
please also look at this patch?

Will do...

Fixed in rpm-4.4.2.2-rc1 in next rawhide push.

Thanks for the patch!