Bug#217589: dpkg: --force-noovewrite option, for not replacing existing files.
On Tue, Apr 12, 2005 at 08:07:11PM +0100, Scott James Remnant wrote:
> On Tue, 2005-04-12 at 13:46 -0500, Mike Mestnik wrote:
>
> > On Fri, Mar 18, 2005 at 02:34:33PM +0000, Scott James Remnant wrote:
> > > Rejected.
> > >
> > > You can either:
> > >
> > > 1) divert files that you intend to deliberately replace.
> > >
> > > 2) add a Replaces: to the installed package on the one you wish to
> > > install, so the one you wish to install only installs files that
> > > differ.
> > >
> > > dpkg has no need for an "only install part of a package, randomly"
> > > option.
> > >
> > I think you miss the point, try reading my message again.
> >
> > 1. I don't think unpacking and repacking a deb is as easy as "mv; dpkg
> > -i; mv;".
> >
> Define "unpacking and repacking" ... ? Unpacking a deb is as easy as
> "dpkg -i" (or just dpkg --unpack). If you want (as a user) to override
> files installed from a deb, use dpkg-divert.
>
I may have misinterpreted you, but you were asking me to modify a
control file before i do a "dpkg -i". This is what led me to think
you are not on the same page, I hope you understand me now.
> > 2. I still don't think this works for this case. Would "Replace:
> > lilo" cause these files to be saved? The files I'm talking about are
> > 'cruft' and not in the pkg database.
> >
> Then dpkg can't handle them, or care about them. dpkg only cares about
> files _in_ the database, for obvious reasons.
>
I don't think destroying things in /root or /home would be wise, YMMV.
Also we do this for conffiles now, I don't see anything ground
breaking in what I'm asking. Simply allow the user to expand these
rules for all files, thought it's not a good idea to ask for every file.
> > I know it's confusing but the default is to not overwrite pkged files,
> > unless they belong to you. What I'm talking about goes one step
> > further, to save files that don't belong to any one.
> >
> That is also the default; attempting to overwrite a file will result in
> an error whether or not it is owned by a package. (There's an exception
> for conffiles, for hopefully obvious reasons).
>
Could you provide an example? It seams if lilo is upgraded then
/usr/bin/lilo would get changed, this dose not seam to be an error as
you describe. In the case where silo owns a symlink called
/usr/bin/lilo, the above is correct. It would be nice to allow silo to
be installed with --force-overwrite, even thought it is already
installed. Like I said many uses, that can not all be covered here.
This is what I'm talking about...
Then "why" did I open this bug in the first place? I think you should
do some testing.
In this case /usr/bin/lilo being not in the database
gets deleted, as thought we where upgrading lilo. Try..
dpkg --purge lilo;
cp /etc/motd /usr/bin/lilo;
apt-get install lilo;
file /usr/bin/lilo; # by this time /usr/bin/lilo is not text.
I agree with this being a good default, it ensures lilo operates
correctly. However in times of need you may only want the /boot files
from lilo installed, leaving my/your copy of /usr/bin/lilo in place.
> Scott
> --
> Have you ever, ever felt like this?
> Had strange things happen? Are you going round the twist?
--
/*********************************************************
* Mike Mestnik: Support Technician 612-395-9010 *
* support@visi.com Visi.com *
*********************************************************/
Reply to: