Comment 6 for bug 431993

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 <email address hidden> http://www.dlasys.net
Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein