I just updated sendmail using yum, and found a sendmail.cf.rpmnew
file. There are numerous changes in this .cf file that seem important,
but they will certainly be overwritten the next time the sendmail
service restarts and the .mc file is processed.
Are we expected to search our existing .mc files, and make them match
the newest changes from the sendmail.cf.rpmnew file? I don't even
believe that all of the changes could be made to match by revising the
.mc file alone.
Wouldn't it make so much more sense for both new sendmail.cf.rpmnew
and a sendmail.mc.rpmnew files to have been distributed?
>>
The fact that in sendmail, the .mc file is used to generate the .cf file
makes this a whole different kind of issue. I have a hard time believing
that providing an updated version of a file that is generated by another
file, and not that other file, could have been intentional.
Unless I'm wrong, many of the revisions CAN'T be made by editing the .mc
file. We'd have to edit the m4 script, and various other sendmail
configuration files that it accesses. If these source files had all been
updated with the new revisions, and we were left to make only the
changes applicable to the .mc file, that would be fine, but I can see
that this is not the case.
>>
>> Steven
I'm not sure there's an issue here.
The .mc file gets processed by m4 and pulls in a bunch of m4 "source"
files that then cause a new generated .cf file to be created.
Since people rarely modify the .m4 files, these get transparently
updated with no generated .rpmnew files.
Agreed, so far.
The resultant .cf file, however, may clash with edits you've made.
Unless you've not made edits, in which case, "yes", the original .cf
file should have been replaced with the new .cf file. Is this not
happening?
My .cf file was not replaced by the new .cf file; thus, the birth of
this thread. It would seem to me the 'clash' you describe is not only
inevitable, but desirable, due to the fact that my .cf file, by
definition, contains the mail settings I entered via my .mc file.
If your .mc file hadn't been modified and neither had your .cf file,
then running "make sendmail.cf" will cause your sendmail.cf to be
regenerated... and agree with your sendmail.mc file, which should always
be the case anyway.
I fully understand and agree that the two files should 'agree', but I
don't see how this clarifies or explains the fact that I see minor, but
certainly differing, lines in the .rpmnew file that do not appear in the
.cf file that is presently generated when I regenerate the file.
Maybe the real question here should be where the differences I see
really stem from. It just seems logical to me that if a .cf file is
being included with a package update, it must be that it contains
elements that no other files can provide to it during a regeneration.
However, maybe this is where I am off base! Does the .cf file get
completely written from scratch by other files during its regeneration,
or is it simply edited during this process? If it is entirely dependent
on outside 'sources' for the entirely of its content, with every line
being entirely system-specific, then why include it with a package
update at all, instead of just letting the end user generate his or her
own .cf file?
As I write, I am beginning to believe that my confusion steps from this
single factor! Why include a .cf file in the package update, at all, if
the .cf file is supposed to reflect the system it is located on?
Suddenly, I begin to feel the clouds part, I contemplate the simplicity
of 'rm /etc/mail/sendmail.cf.rpmnew', and a smile forms on my face...
Can anyone confirm that I am finally seeing the light?
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
