[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Proposal - don't install .rpmnew unless changed



2006/1/19, Neal Becker <ndbecker2 gmail com>:
> Paul Howarth wrote:
>
> > Neal Becker wrote:
> >> Paul Howarth wrote:
> >>>Neal Becker wrote:
> >>>>Paul Howarth wrote:
> >>>>>Neal Becker wrote:
> >>>>>>It would save admins a lot of time if we modify rpm so that it does
> >>>>>>not
> >>>>>>create a .rpmnew file if there is no change from the old file.  I
> >>>>>>would think this would be a simple modification.
> >>>>>
> >>>>>It already does this, doesn't it?
> >>>>>
> >>>>
> >>>>
> >>>>I don't think so!  I keep syncing with develop every day, and most days
> >>>>I get a bunch of messages about "blah created as .rpmnew", and every day
> >>>>I run diff, and almost always get no output.
> >>>
> >>>Are you on an x86_64 box with lots of parallel-installed i386 packages?
> >>>
> >>
> >>
> >> Yes, x86_64.  I have most parallel i386 packages that are standard on
> >> x86_64.  I did not install extra i386 packages.
> >>
> >> Today, for example, there were a bunch of messages about upgrade to
> >> kdelibs-3.5.0-5.  It does happen that there are both x86_64 and i386
> >> versions of this, do you think this is the explanation?  In any case, any
> >> chance to fix it?
> >
> > I think it's the same issue (multiple packages owning the same config
> > file) as for /etc/vimrc, except in this case it's different-arch
> > packages instead of different-name packages.
> >
> > I don't know what the *right* policy for these cases should be really.
> >
>
> Isn't it "right" to not create .rpmnew and report it to the user if there is
> no diff to the current version?
>
> --
> fedora-devel-list mailing list
> fedora-devel-list redhat com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>

yes if there were no manual or toolbased (config frontend) changes to
that config file it should just be upgraded to the default config of
the new package.
of course the %config option has various possible attributes a packager can set.

regards,
Rudolf Kastl


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]