Colin Watson wrote: > On Tue, Oct 06, 2009 at 11:07:05PM -0000, dhlii wrote: > >> And honestly I am not sure that I accept that you have to delete >> anything. I grasp that you must replace numerous files, that to ensure a >> working and robust system you must replace libraries that are found with >> those that match this particular install - it is even useful to be able >> to go backwards - re-install intrepid over karmic as an example. >> >> But off the top of my head I can think of extremely few instances >> where if standards are being followed the mere presence of a file from a >> previous install should destabalize a system. There are a few instances >> but they seem to be unique to things like udev that act on any file >> present in a given directory. >> > > On the contrary, there are lots and lots of situations where we check > for the presence or absence of a file. For instance, it's standard for > init scripts to check for the presence of a binary before proceeding. > That is not directly comparable. I have accepted that you are going to clean out the initscripts. Given that you have done that, and the binary for xyz is still present, there is no initscript to fire it off so it will not start. Of course if the user/administrator wanted to start it they still could. So long as the only things you deleted where those that were explicitly part of the bootup execution path most everything else on the system including package configuration files could safely remain. > Many programs have cascading conditionals which check for one > alternative after another (gnome-wm comes quickly to mind as a fairly > dramatic example, but it's just one example). The result of not cleaning > up old system files is, in very many cases, quite likely to be a broken > system. > I have only dealt with ubuntu for a few years, But I have been dealing with debian systems for about a decade, It is a very common occurance to do an install directly ontop of an a broken system to repair it. And it virtually always works. It is one area at which Linux excells. It is extremely difficult to do this with windows. I am not particularly familiar with gnome-wm. But even there why are you presuming that you will end up with something broken. You already seem to deliberately preserve existing home directories and the configurations present there. That means that it is highly likely the new install will still have a user gnome configuration matching the prior install. If it is broken - it likely will stay broken. Regardless, the FUNDIMENTAL point is that the choice belongs to the user. It is not the job of the installer to decide that what I have chosen to do is stupid and silently override my decision. If I choose to install onto a dirty system while it is acceptable to ask if that is really what I want to do, and maybe acceptable to do some deletion if I say no, it is not acceptable to delete anything that is not explicitly going to interfere with building the system whether it is in the /usr tree or /etc or .... > My greatest worry (which I think is very well-founded) about leaving old > system files around is that they will never be upgraded and yet there's > a good chance that they'll be used anyway. In this day and age where > security vulnerabilities might lurk nearly anywhere, and where people > expect that in general bug fixes will be applied automatically on > upgrade, I just don't think that's a tenable policy. > I have not read the debian policy manual in some time, but I am pretty sure this is already spelled out. Regardless, the point still is, it is not the installers job to silently protect me from what it views as my own stupidity. Further you are following a long chain of presumptions. First, you are presuming that even though I chose to install over an existing system that was not really what I wanted to do. That the files lying arround are actually old files - they could easily be from the current version. that they will get used that they never will get upgraded that they contain some kind of security vulnerability. I see zero problem with canonical disclaiming support for a dirty install. I am not asking that they work out all the details of how to guarantee that an install over a dirty system will result in something that works. All I am asking is that the installer not deprive me of the choice to do exactly that. > >> Anyway with respect to principles and policy I think the best >> approach is for the installer to complain and make note of the presence >> of files in system directories. >> I do not care if you tell the user this is unsupported. >> > > Frankly, I'd rather that the feature of installing over the top of an > existing system without reformatting weren't supported at all, but it > was added due to overwhelming demand. Going back and telling people that > it's unsupported (since there will be mismatching files in system > directories in nearly all cases) doesn't seem likely to help. > And be indiscriminately deleting files you are completely subverting the very reason people want it in the first place. Next it is not a feature that was added. It has been present as part of linux since the very begining. Your conclusion that there will be mismatches all over - is a presumption not necescarily a fact. The normal reasons for doing a dirty install are to repair a non-booting or otherwise damaged system. The norm in that instance will be to re-install exactly the same version - or atleast something very close. The only thing that will be out of sync is the database of installed packages , and most of the people asking for this know how to address that too. If after the install I do a reinstall of every package that was on the system before I should not end up with any of the scenarios that concern you. Regardless, it is my choice and my risk. At the bottom of this, I do not think you are violating just my wishes, or the wishes of many others you have feedback from, but I think you have gone astray from existing policies. I am not some kind of LSB or FSF or debian policy wonk, but I can not possibly beleive that any of those groups would allow the deletion of anything on an existing filesystem without atleast 10 pages of policy on what can and can't be done. And while I do not tend to take those things to the legalistic extreme some of those people do, usually they get things very nearly right. >> The second is that there appears to be an actual intent to get >> much more aggressive about file deletion. >> > > No more so than at present; indeed your bug suggests that we need to be > more surgical about it, and I think that's our planned response to this > bug What I am suguesting is that when you install on a dirty system, that you do not delete anything without permission except: the specific files that would be installed as part of a new install. files or links in directories that are part of the boot process that are executed by virtue of their presence rather than their name. Such as those files or links in the udev directories or the rc#.d directories. aside from that packages should follow their normal rules. I am not sugesting that anything be changed about the way any package handles its installation process. Even if the package does not conform to existing policies, that problem belongs to the package maintainer and not the installation system. I suspect that if you just made the rule do not do anything for a package that it would ordinarily be responsible for itself, the rest would take care of itself. What files is the installer responsible for that are entirely independent of the package system ? -- Dave Lynch DLA Systems Software Development: Embedded Linux 717.627.3770