1:15 p.m.
Hello,
(If you are on a Bcc:, this e-mail directly affects one of your
packages.)
Because the Fedora 11 RPM packages will use SHA-256 for file digests in
the RPM headers, upgrades from earlier releases to Fedora 11 will
replace user-modified %config files (without noreplace) by their
original versions, and rename the user-modified files to *.rpmsave.
The Fedora packaging guidelines already suggest using %config(noreplace)
in most cases:
https://fedoraproject.org/wiki/PackagingGuidelines#Configuration_files .
Please review use of %config without noreplace in your packages, and add
noreplace if appropriate. The list of affected packages is below.
Mirek
abompard pure-ftpd
abompard tiger
adrian jabberd
ajax system-config-display
amdunn coq
ashawley gnue-common
astokes sos
athimm apt
athimm fedora-package-config-apt
athimm smart
atkac bind
atkac enscript
atkac rsh
atorkhov ember
ausil snort
awjb odccm
awjb synce-serial
awjb WindowMaker
behdad fontconfig
behdad pango
buc phpldapadmin
buc phpwapmail
caolanm openoffice.org
cassmodiah sbackup
clumens firstboot
davej midisport-firmware
davidf fsvs
davidz dbus
davidz notification-daemon
dbhole jpackage-utils
dcantrel dhcpv6
dcbw NetworkManager
deebs phpTodo
denis brasero
dledford lam
dnovotny emacs
dwalsh selinux-policy
dwalsh setroubleshoot
dwmw2 apmud
dwmw2 exim
dwmw2 linux-atm
edhill wifiroamd
emunson lsvpd
ensc clamav
ensc dhcp-forwarder
ensc fedora-usermgmt
ensc ip-sentinel
ensc kismet
ensc tor
ensc util-vserver
frankb ctapi-cyberjack
gemi smarteiffel
geoff scala
giallu alleyoop
hadess bluez
hadess bluez-gnome
hadess galago-daemon
hadess gnome-media
hadess gnome-vfs2-obexftp
hadess totem
harald readahead
harald udev
herlo darkice
huzaifas psiconv
chitlesh alliance
icon epylog
ixs bacula
ixs ices
jakub glibc
jamatos ifplugd
jbowes gnome-nds-thumbnailer
jcm module-init-tools
jkeating fedora-release
jmoskovc lynx
jmoskovc rarpd
jmoskovc rusers
jmoskovc rwall
jmoskovc rwho
jnovy mc
jorton httpd
jorton php
jorton php-pear
jparsons system-config-cluster
jskala arptables_jf
jskala mgetty
jskala ppp
jskala quagga
jskala squid
jspaleta revelation
jwboyer quilt
kaboom rinetd
karsten irda-utils
karsten x3270
katzj yum-updatesd
kevin p0f
kushal kphotobymail
kwizart aqsis
kwizart color-filesystem
kwizart elektra
kwizart PythonCAD
kzak gnome-applet-vm
lennart pulseaudio
limb wesnoth
lkundrak grub2
lkundrak system-config-keyboard
lkundrak system-config-rootpassword
lvm-team device-mapper-multipath
mccann ConsoleKit
mccann gdm
mcleanj nxt_python
mhlavink nmap
mhlavink nut
mhlavink squirrelmail
mlichvar arpwatch
mlichvar conky
mlichvar pinfo
mlichvar sendmail
mmahut gnuradio
mpg sugar
nalin krb5
nalin oddjob
nbecker filelight
nhorman kexec-tools
nigelj horde
nigelj imp
nigelj ingo
nigelj jeta
nigelj kronolith
nigelj turba
notting initscripts
ovasik inn
ovasik wvdial
overholt eclipse
perex alsa-lib
perex alsa-utils
pertusus gnochm
pertusus wdm
peter fuse
petersen thaifonts-scalable
pghmcfc gnome-libs
phuang ibus
pjones mkinitrd
pknirsch filesystem
pknirsch system-config-httpd
pwouters driftnet
rathann comgt
rdieter dirmngr
rdieter kde-filesystem
rdieter kde-settings
rezso mapbender
rhughes hal
rhughes PackageKit
rrelyea ccid
rrelyea pcsc-lite
rstrode gnome-mime-data
rstrode libbonobo
rstrode redhat-menus
salimma zeroinstall-injector
scop vdr
scop w3c-markup-validator
sgrubb prelude-lml
sgrubb prelude-manager
silfreed thinkfinger
skvidal system-autodeath
spot generic-release
steved nfs-utils
steved rpcbind
steve openvpn
steve qtparted
steve sqlgrey
stransky nspluginwrapper
tagoh Canna
tagoh kinput2
tbzatek gnome-vfs2
than isdn4k-utils
than mozplugger
than qt3
thias gentoo
thias lighttpd
thias oidentd
thias proftpd
thomasvs flumotion
thomasvs mach
till latex-mk
till wyrd
tmraz pam
twaugh a2ps
twaugh expendable
twaugh ghostscript
twaugh pnm2ppa
twoerner system-config-firewall
varekova psacct
vcrhonek tog-pegasus
vcrhonek ypserv
xen-maint xen
xgl-maint xorg-x11-twm
xgl-maint xorg-x11-xdm
xgl-maint xorg-x11-xsm
zkota pybliographer
zprikryl apmd
zprikryl fbset
4:34 p.m.
On Tue, Feb 24, 2009 at 8:15 PM, Miloslav Trmač <mitr(a)volny.cz> wrote:
Please review use of %config without noreplace in your packages, and add
noreplace if appropriate. The list of affected packages is below.
<snip>
giallu alleyoop
this is because of:
%config %{_sysconfdir}/gconf/schemas/*.schemas
I checked other packages and it seems they are not marking with
%config the files in /etc/gconf/schemas.
So, may I safely drop this?
In that case, maybe rpmlint should grow a rule to not return:
alleyoop.i386: W: non-conffile-in-etc /etc/gconf/schemas/alleyoop.schemas
on the resulting rpm?
--
Gianluca Sforna
http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna
8:06 p.m.
Gianluca Sforna wrote:
On Tue, Feb 24, 2009 at 8:15 PM, Miloslav Trmač <mitr(a)volny.cz>
wrote:
> Please review use of %config without noreplace in your packages, and add
> noreplace if appropriate. The list of affected packages is below.
<snip>
> giallu alleyoop
this is because of:
%config %{_sysconfdir}/gconf/schemas/*.schemas
I checked other packages and it seems they are not marking with
%config the files in /etc/gconf/schemas.
So, may I safely drop this?
Yes, gconf schemas are data, not %config.
In that case, maybe rpmlint should grow a rule to not return:
alleyoop.i386: W: non-conffile-in-etc /etc/gconf/schemas/alleyoop.schemas
on the resulting rpm?
File a bug and let the rpmlint maintainers see what they think.
-Toshio
9:44 a.m.
2009/2/25 Toshio Kuratomi <a.badger(a)gmail.com>:
Gianluca Sforna wrote:
> So, may I safely drop this?
Yes, gconf schemas are data, not %config.
Ok.
> In that case, maybe rpmlint should grow a rule to not return:
> alleyoop.i386: W: non-conffile-in-etc /etc/gconf/schemas/alleyoop.schemas
> on the resulting rpm?
File a bug and let the rpmlint maintainers see what they think.
http://rpmlint.zarb.org/cgi-bin/trac.cgi/ticket/176
Thank you for the advices
--
Gianluca Sforna
http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna
12:23 p.m.
On Tue, 2009-02-24 at 18:06 -0800, Toshio Kuratomi wrote:
Gianluca Sforna wrote:
> On Tue, Feb 24, 2009 at 8:15 PM, Miloslav Trmač <mitr(a)volny.cz> wrote:
>> Please review use of %config without noreplace in your packages, and add
>> noreplace if appropriate. The list of affected packages is below.
> <snip>
>> giallu alleyoop
>
> this is because of:
> %config %{_sysconfdir}/gconf/schemas/*.schemas
>
> I checked other packages and it seems they are not marking with
> %config the files in /etc/gconf/schemas.
>
> So, may I safely drop this?
Yes, gconf schemas are data, not %config.
> In that case, maybe rpmlint should grow a rule to not return:
> alleyoop.i386: W: non-conffile-in-etc /etc/gconf/schemas/alleyoop.schemas
> on the resulting rpm?
File a bug and let the rpmlint maintainers see what they think.
Isn't the bug more likely in gconf? If these are data they should not be
in /etc but /usr (according to FHS).
I note that openSUSE has a feature request for this:
https://features.opensuse.org/305318
which claims that Debian does it already. What's upstream's take on
this?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:27 p.m.
Adam Williamson wrote:
On Tue, 2009-02-24 at 18:06 -0800, Toshio Kuratomi wrote:
> Gianluca Sforna wrote:
>> On Tue, Feb 24, 2009 at 8:15 PM, Miloslav Trmač <mitr(a)volny.cz> wrote:
>>> Please review use of %config without noreplace in your packages, and add
>>> noreplace if appropriate. The list of affected packages is below.
>> <snip>
>>> giallu alleyoop
>> this is because of:
>> %config %{_sysconfdir}/gconf/schemas/*.schemas
>>
>> I checked other packages and it seems they are not marking with
>> %config the files in /etc/gconf/schemas.
>>
>> So, may I safely drop this?
> Yes, gconf schemas are data, not %config.
>
>> In that case, maybe rpmlint should grow a rule to not return:
>> alleyoop.i386: W: non-conffile-in-etc /etc/gconf/schemas/alleyoop.schemas
>> on the resulting rpm?
> File a bug and let the rpmlint maintainers see what they think.
Isn't the bug more likely in gconf? If these are data they should not be
in /etc but /usr (according to FHS).
I note that openSUSE has a feature request for this:
https://features.opensuse.org/305318
which claims that Debian does it already. What's upstream's take on
this?
This has been discussed before on both Fedora and upstream lists. IIRC,
upstream admitted it's a flaw but decided that making changes had the
potential to break too much existing software.
If you have the energy to move this forward I'd agree that %{_datadir}
is a better place for it and if Debian's been successful in moving
schemas there, it might invalidate the breakage argument.
-Toshio
12:29 p.m.
On Wed, 2009-02-25 at 10:23 -0800, Adam Williamson wrote:
On Tue, 2009-02-24 at 18:06 -0800, Toshio Kuratomi wrote:
> Gianluca Sforna wrote:
> > On Tue, Feb 24, 2009 at 8:15 PM, Miloslav Trmač <mitr(a)volny.cz> wrote:
> >> Please review use of %config without noreplace in your packages, and add
> >> noreplace if appropriate. The list of affected packages is below.
> > <snip>
> >> giallu alleyoop
> >
> > this is because of:
> > %config %{_sysconfdir}/gconf/schemas/*.schemas
> >
> > I checked other packages and it seems they are not marking with
> > %config the files in /etc/gconf/schemas.
> >
> > So, may I safely drop this?
>
> Yes, gconf schemas are data, not %config.
>
> > In that case, maybe rpmlint should grow a rule to not return:
> > alleyoop.i386: W: non-conffile-in-etc /etc/gconf/schemas/alleyoop.schemas
> > on the resulting rpm?
>
> File a bug and let the rpmlint maintainers see what they think.
Isn't the bug more likely in gconf? If these are data they should not be
in /etc but /usr (according to FHS).
I note that openSUSE has a feature request for this:
https://features.opensuse.org/305318
which claims that Debian does it already. What's upstream's take on
this?
We may reopen this discussion upstream after 2.26, and see if we can
achieve some harmonization of GConf paths between distros.
So far, we have not taken this up (moving schemas from /etc to /usr),
since it is a change that affects many packages, without any tangible
benefits. Unless you want to count an FHS checkbox or 'silent rpmlint'
as a benefit that warrants non-trivial (it is not just file lists, but %
post/%pre/%preun scripts too) changes in tons of packages...
3:02 p.m.
On Wed, Feb 25, 2009 at 7:23 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
Isn't the bug more likely in gconf? If these are data they should not be
in /etc but /usr (according to FHS).
Which is also the opinion of rpmlint developers upstream (my report
closed as wontfix)
So if we want to silence it the only way left looks like patching
rpmlint code downstream. See also:
https://bugzilla.redhat.com/show_bug.cgi?id=235487
--
Gianluca Sforna
http://morefedora.blogspot.com
http://www.linkedin.com/in/gianlucasforna
3:27 p.m.
On Wednesday 25 February 2009, Gianluca Sforna wrote:
On Wed, Feb 25, 2009 at 7:23 PM, Adam Williamson
<awilliam(a)redhat.com>
wrote:
> Isn't the bug more likely in gconf? If these are data they
should not be
> in /etc but /usr (according to FHS).
Which is also the opinion of rpmlint developers upstream (my report
closed as wontfix)
So if we want to silence it the only way left looks like patching
rpmlint code downstream. See also:
https://bugzilla.redhat.com/show_bug.cgi?id=235487
No need to patch nor even update to rpmlint, all it takes is one addFilter()
line in some of rpmlint's config files, for example /etc/rpmlint/my.config or
~/.rpmlintrc
addFilter("non-conffile-in-etc /etc/gconf/schemas")
If FPC finds it necessary, this can be included in future default rpmlint
configs in Fedora. Just let me know (preferably in the above Bugzilla
entry).
But as explained in the upstream rpmlint ticket, this is only half of what's
apparently desired - it will mute the warning, but won't issue another if a
schema file *is* marked as %config while being in /etc. IMO it'd be better
to just move the schemas to a more FHS compliant location than to start
adding any workarounds in rpmlint.
4:01 p.m.
Miloslav Trmač (mitr(a)volny.cz) said:
Because the Fedora 11 RPM packages will use SHA-256 for file digests
in
the RPM headers, upgrades from earlier releases to Fedora 11 will
replace user-modified %config files (without noreplace) by their
original versions, and rename the user-modified files to *.rpmsave.
The Fedora packaging guidelines already suggest using %config(noreplace)
in most cases:
https://fedoraproject.org/wiki/PackagingGuidelines#Configuration_files .
Please review use of %config without noreplace in your packages, and add
noreplace if appropriate. The list of affected packages is below.
Given that it's comparing hashes, and the old hash is *obviously* of a
different type than the new hash, why can't these sorts of conflicts
be caught?
Bill
4:12 p.m.
Bill Nottingham píše v St 25. 02. 2009 v 17:01 -0500:
Miloslav Trmač (mitr(a)volny.cz) said:
> Because the Fedora 11 RPM packages will use SHA-256 for file digests in
> the RPM headers, upgrades from earlier releases to Fedora 11 will
> replace user-modified %config files (without noreplace) by their
> original versions, and rename the user-modified files to *.rpmsave.
>
> The Fedora packaging guidelines already suggest using %config(noreplace)
> in most cases:
> https://fedoraproject.org/wiki/PackagingGuidelines#Configuration_files .
>
> Please review use of %config without noreplace in your packages, and add
> noreplace if appropriate. The list of affected packages is below.
Given that it's comparing hashes, and the old hash is *obviously* of a
different type than the new hash, why can't these sorts of conflicts
be caught?
rpm recognizes that the hash changed, but what can it do?
- there is a config file
- the config file was modified by the user
- the update package may or may not contain a different version
of the config file than the old package.
=> the only things rpm can do is:
- leave the modified config file as is
(this is what rpm does if the hashes are equal, i.e. the update
doesn't change the config file)
X if the update did update the config file, the updated config file
would not be installed - but %config means the updated config file
should be installed
X this loses data (user would have to dig into the updated rpm package
manually to get the updated config file, and would get no
notification about the unused updated config file)
- save the updated config file as .rpmnew
X there would be no difference between %config and %config(noreplace),
changing the semantics
- save the modified config file as .rpmsave
X moves modified files to .rpmsave even if the update doesn't change
the config file
Mirek
4:19 p.m.
On Wed, 25 Feb 2009 23:12:13 +0100
Miloslav Trmač <mitr(a)volny.cz> wrote:
Bill Nottingham píše v St 25. 02. 2009 v 17:01 -0500:
> Miloslav Trmač (mitr(a)volny.cz) said:
> > Because the Fedora 11 RPM packages will use SHA-256 for file
> > digests in the RPM headers, upgrades from earlier releases to
> > Fedora 11 will replace user-modified %config files (without
> > noreplace) by their original versions, and rename the
> > user-modified files to *.rpmsave.
> >
> > The Fedora packaging guidelines already suggest using
> > %config(noreplace) in most cases:
> > https://fedoraproject.org/wiki/PackagingGuidelines#Configuration_files .
> >
> > Please review use of %config without noreplace in your packages,
> > and add noreplace if appropriate. The list of affected packages
> > is below.
>
> Given that it's comparing hashes, and the old hash is *obviously*
> of a different type than the new hash, why can't these sorts of
> conflicts be caught?
rpm recognizes that the hash changed, but what can it do?
- there is a config file
- the config file was modified by the user
- the update package may or may not contain a different version
of the config file than the old package.
=> the only things rpm can do is:
- leave the modified config file as is
(this is what rpm does if the hashes are equal, i.e. the update
doesn't change the config file)
X if the update did update the config file, the updated config file
would not be installed - but %config means the updated config file
should be installed
X this loses data (user would have to dig into the updated rpm
package manually to get the updated config file, and would get no
notification about the unused updated config file)
- save the updated config file as .rpmnew
X there would be no difference between %config and
%config(noreplace), changing the semantics
- save the modified config file as .rpmsave
X moves modified files to .rpmsave even if the update doesn't change
the config file
rpm could compute the old format hash of the config file it's about to
install and compare it with the old format hash (from the existing
rpmdb) of the installed and possibly modified config file; if the old
format hashes are the same, the config file did not change between the
old and new package and it can be left as-is.
Is there some flaw in that plan?
Paul.
4:26 p.m.
On Wed, 2009-02-25 at 23:12 +0100, Miloslav Trmač wrote:
Bill Nottingham píše v St 25. 02. 2009 v 17:01 -0500:
> Miloslav Trmač (mitr(a)volny.cz) said:
> > Because the Fedora 11 RPM packages will use SHA-256 for file digests in
> > the RPM headers, upgrades from earlier releases to Fedora 11 will
> > replace user-modified %config files (without noreplace) by their
> > original versions, and rename the user-modified files to *.rpmsave.
> >
> > The Fedora packaging guidelines already suggest using %config(noreplace)
> > in most cases:
> > https://fedoraproject.org/wiki/PackagingGuidelines#Configuration_files .
> >
> > Please review use of %config without noreplace in your packages, and add
> > noreplace if appropriate. The list of affected packages is below.
>
> Given that it's comparing hashes, and the old hash is *obviously* of a
> different type than the new hash, why can't these sorts of conflicts
> be caught?
rpm recognizes that the hash changed, but what can it do?
- there is a config file
- the config file was modified by the user
- the update package may or may not contain a different version
of the config file than the old package.
=> the only things rpm can do is:
- leave the modified config file as is
(this is what rpm does if the hashes are equal, i.e. the update
doesn't change the config file)
X if the update did update the config file, the updated config file
would not be installed - but %config means the updated config file
should be installed
X this loses data (user would have to dig into the updated rpm package
manually to get the updated config file, and would get no
notification about the unused updated config file)
- save the updated config file as .rpmnew
X there would be no difference between %config and %config(noreplace),
changing the semantics
- save the modified config file as .rpmsave
X moves modified files to .rpmsave even if the update doesn't change
the config file
As already pointed out by someone else before. RPM could compute
on-the-fly the old (MD5) hash of the new config file being installed and
use that for the comparsion. Except this may not be easily hackable into
the RPM code I suppose because the file is possibly not yet extracted
from the cpio at the time the hashes are compared.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
5:16 p.m.
Tomas Mraz wrote:
As already pointed out by someone else before. RPM could compute
on-the-fly the old (MD5) hash of the new config file being installed and
use that for the comparsion. Except this may not be easily hackable into
the RPM code I suppose because the file is possibly not yet extracted
from the cpio at the time the hashes are compared.
I think the best solution would be for RPMs to carry BOTH SHA256 and MD5
checksums for %config files, SHA256 being used for all operations with the
new RPM, but the MD5 for comparisons with the old MD5. This could then be
phased out after a couple of releases.
Kevin Kofler
5:55 a.m.
On Wednesday 25 February 2009 22:01:12 Bill Nottingham wrote:
Given that it's comparing hashes, and the old hash is *obviously*
of a
different type than the new hash, why can't these sorts of conflicts
be caught?
The hash for the original file is stored in the rpm database, as part of the
headers. Why wasn't a new tag created, or why doesn't the new shiny rpm mark
the entry in some way to indicate that it's a "new" hash? Isn't the new
hash
bigger anyway? In which case it should be able to tell what kind of hash it is
(just like the password encryption routines can recognise the difference
between an md5 and an sha1 hash) ... and run the old checksum code on the file
on the machine, before replacing it with the new file and the new hash.
Is this actually rocket science?
7:01 a.m.
Bill Crawford píše v Čt 26. 02. 2009 v 11:55 +0000:
The hash for the original file is stored in the rpm database, as part
of the
headers.
Sure.
Why wasn't a new tag created, or why doesn't the new shiny
rpm mark
the entry in some way to indicate that it's a "new" hash?
There is a
new tag.
Isn't the new hash
bigger anyway? In which case it should be able to tell what kind of hash it is
(just like the password encryption routines can recognise the difference
between an md5 and an sha1 hash)
Of course rpm can tell.
... and run the old checksum code on the file
on the machine, before replacing it with the new file and the new hash.
That
answers the question whether the user has modified the file. It
doesn't answer the question whether the packager has modified the
shipped file between the two rpm package versions.
Is this actually rocket science?
I don't know, is rpm used
on rocket guidance systems nowadays?
Mirek
7:50 a.m.
On Thursday 26 February 2009 13:01:07 Miloslav Trmač wrote:
Bill Crawford píše v Čt 26. 02. 2009 v 11:55 +0000:
...
> ... and run the old checksum code on the file
> on the machine, before replacing it with the new file and the new hash.
That answers the question whether the user has modified the file. It
doesn't answer the question whether the packager has modified the
shipped file between the two rpm package versions.
But that's the question we should be asking ... right?
7:22 a.m.
Bill Crawford <billcrawford1970(a)gmail.com> wrote:
On Thursday 26 February 2009 13:01:07 Miloslav Trmač wrote:
> Bill Crawford píše v Čt 26. 02. 2009 v 11:55 +0000:
...
> > ... and run the old checksum code on the file
> > on the machine, before replacing it with the new file and the new hash.
>
> That answers the question whether the user has modified the file. It
> doesn't answer the question whether the packager has modified the
> shipped file between the two rpm package versions.
But that's the question we should be asking ... right?
No.
There are 3 potential files involved:
A: The original configuration as given by the installed package
B: The installed configuration file (as modified by the user)
C: The new configuration file.
If B == A, rpm can safely replace the configuration file by C.
If A != B, the user changed something, and the changes have to be ported
forward by hand.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
8:03 a.m.
On Monday 02 March 2009 13:22:29 Horst H. von Brand wrote:
Bill Crawford <billcrawford1970(a)gmail.com> wrote:
> On Thursday 26 February 2009 13:01:07 Miloslav Trmač wrote:
> > Bill Crawford píše v Čt 26. 02. 2009 v 11:55 +0000:
>
> ...
>
> > > ... and run the old checksum code on the file
> > > on the machine, before replacing it with the new file and the new
> > > hash.
> >
> > That answers the question whether the user has modified the file. It
> > doesn't answer the question whether the packager has modified the
> > shipped file between the two rpm package versions.
>
> But that's the question we should be asking ... right?
No.
There are 3 potential files involved:
A: The original configuration as given by the installed package
B: The installed configuration file (as modified by the user)
C: The new configuration file.
If B == A, rpm can safely replace the configuration file by C.
If A != B, the user changed something, and the changes have to be ported
forward by hand.
That's ... sort of my point. RPM only has to compare the existing hash in the
rpmdb, with that of the file currently on the disk. This doesn't need to care
about the new file at all ('C' doesn't appear in your 'if'
conditions).
Now, if we see that the original file was unmodified (at least according to md5
AND timestamp / size) then we replace it, and don't need to care whether the
new file is different to the original.
If it's apparently changed, we're going to save it to one side (.rpmsave, or, if
it's a "noreplace" file, then save the new one as .rpmnew). Why do we need
to
care whether the new config file has changed in the package, if the file has
been modified on disk? If it hasn't, just re-hash that file with your new hash
algorithm, and compare *that* with the new package's version of the file. If
you're worried there might be a hash collision with md5, but not with sha-xxx,
then always save the new file as .rpmnew, or something.
9:40 a.m.
"Horst H. von Brand" <vonbrand(a)inf.utfsm.cl> writes:
A: The original configuration as given by the installed package
B: The installed configuration file (as modified by the user)
C: The new configuration file.
If B == A, rpm can safely replace the configuration file by C.
If A != B, the user changed something, and the changes have to be ported
forward by hand.
If C == A and B != A, then there's no point in replacing the
configuration file, and doing so is a great pain. It took forever for
Fedora to get this right, but since 7 or so it has been working very
nicely. (Except when upstream puts the user guide in the configuration
files and then reformats or spell checks).
/Benny
10:24 a.m.
Miloslav Trmač wrote:
Bill Crawford píše v Čt 26. 02. 2009 v 11:55 +0000:
> Isn't the new hash
> bigger anyway? In which case it should be able to tell what kind of hash it is
> (just like the password encryption routines can recognise the difference
> between an md5 and an sha1 hash)
Of course rpm can tell.
> ... and run the old checksum code on the file
> on the machine, before replacing it with the new file and the new hash.
That answers the question whether the user has modified the file. It
doesn't answer the question whether the packager has modified the
shipped file between the two rpm package versions.
mitr, it would help if you actually answer the question that everyone's
trying to ask even if they aren't phrasing it right :-)
1. rpmdb has md5 of old vanilla config file.
2. rpm package has sha256 of vanilla new config file.
3. rpm computes md5 of config on filesystem
4. rpm sees that md5 of config on filesystem and config of vanilla file
differ => user has modified file.
5. rpm sees the vanilla hashes are of different type.
6. rpm computes md5 of vanilla new config file.
7. rpm compares md5 of both vanilla config files to determine whether
the packager has modified the file.
You told me on IRC that this wasn't realistic because rpm would have to
open the file twice. Care to elaborate so everyone can understand?
-Toshio
10:51 a.m.
Toshio Kuratomi píše v Čt 26. 02. 2009 v 08:24 -0800:
mitr, it would help if you actually answer the question that
everyone's
trying to ask even if they aren't phrasing it right :-)
1. rpmdb has md5 of old vanilla config file.
2. rpm package has sha256 of vanilla new config file.
3. rpm computes md5 of config on filesystem
4. rpm sees that md5 of config on filesystem and config of vanilla file
differ => user has modified file.
5. rpm sees the vanilla hashes are of different type.
6. rpm computes md5 of vanilla new config file.
7. rpm compares md5 of both vanilla config files to determine whether
the packager has modified the file.
You told me on IRC that this wasn't realistic because rpm would have to
open the file twice. Care to elaborate so everyone can understand?
RPM API users
set up a callback that is, among other things, used to
provide the downloaded package file to RPM. Calling this callback where
it wasn't called before is an API change, possibly breaking the RPM
front-ends.
Implementing the hash recomputation and verifying the API users was a
possibility, but me and Panu consider the current solution good enough -
after all, the user's modified config file would be moved to .rpmsave
even if the package maintainer only added a comment somewhere; not
handling this correctly in rpm does not put any significant additional
burden on our users.
In addition, if the hashes are recomputed, they must be recomputed only
once - decompressing a package five or ten times during a transaction
just wouldn't do - and keeping all recomputed hashes in memory would
increase memory requirements; I was told that minimizing the increase of
memory requirements was a significant reason why the RPM files do not
contain both kinds of hashes simultaneously.
Mirek
11:52 a.m.
On Thu, 2009-02-26 at 16:51 +0000, Miloslav Trmač wrote:
> You told me on IRC that this wasn't realistic because rpm
would have to
> open the file twice. Care to elaborate so everyone can understand?
RPM API users set up a callback that is, among other things, used to
provide the downloaded package file to RPM. Calling this callback where
it wasn't called before is an API change, possibly breaking the RPM
front-ends.
How about computing _both_ an md5 and sha256 hash at the same time when
the rpmdb still has an md5 hash for that file ?
David
12:17 p.m.
David Lutterkort píše v Čt 26. 02. 2009 v 17:52 +0000:
How about computing _both_ an md5 and sha256 hash at the same time
when
the rpmdb still has an md5 hash for that file ?
As I have explained before, hash
of the physical file is easy to
compute, and it's not the one rpm needs and can't get.
Mirek
7:27 a.m.
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
[...]
mitr, it would help if you actually answer the question that
everyone's
trying to ask even if they aren't phrasing it right :-)
1. rpmdb has md5 of old vanilla config file.
2. rpm package has sha256 of vanilla new config file.
3. rpm computes md5 of config on filesystem
4. rpm sees that md5 of config on filesystem and config of vanilla file
differ => user has modified file.
--> Need to keep modified file and install new one, user has to apply
local changes by hand.
5. rpm sees the vanilla hashes are of different type.
6. rpm computes md5 of vanilla new config file.
7. rpm compares md5 of both vanilla config files to determine whether
the packager has modified the file.
This is irrelevant. Just install the new configuration file. If it
didn't change since the installed version, nothing (relevant)
changed. If it changed, it is now the vanilla configuration, just as for
a install (not update).
You told me on IRC that this wasn't realistic because rpm would
have to
open the file twice. Care to elaborate so everyone can understand?
Strange, true.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
5527
days inactive
5533
days old
25 comments
15 participants
participants (15)
-
Adam Williamson -
Benny Amorsen -
Bill Crawford -
Bill Nottingham -
David Lutterkort -
Gianluca Sforna -
Horst H. von Brand -
José Abílio Matos -
Kevin Kofler -
Matthias Clasen -
Miloslav Trmač -
Paul Howarth -
Tomas Mraz -
Toshio Kuratomi -
Ville Skyttä