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 * * [EMAIL PROTECTED] Visi.com * *********************************************************/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
