Re: Autoinstall, upgrade, etc
Jason Gunthorpe wrote:
>
> > 2) If they click on the remove button, instead of selecting it for
> > delete, beep and then display in the status line why it wouldn't let you
> > remove this package.
>
> I think this one is going to be simplest to do.
Good. It's the best solution too IMHO.
> > I don't think upgrading packages is an option, and deleting the
> > dependant packages is a bit too draconian for my tastes.
>
> Well, for instance, if all your packages are set to 'bo' and your remove
> libc5 upgrading everything to 'hamm' (and libc6) will correct the
> situation..
True, however, the way deity is designed, you wouldn't upgrade libc6.
(in fact I would hope most people would allow the correct libraries to
be installed as necessary by their dependencies.) The way to do this is
to upgrade those programs to the libc6 versions (which will, of course,
install libc6). Once the last package that uses libc5 is removed (or
upgraded) libc5 would be auto-removed.
When I said "it wasn't an option", I was trying to say that I didn't
like the idea.
> > Under normal circumstances, especially the way Debian is intergrated
> > (and dependencies/conflicts checked) there should never be a problem in
> > installing a package. I know this isn't always true, but I think any
> > alternative to this voids most of the usefulness of an auto-upgrade
> > tool. In general, if the user upgraded last time the user wants to
> > upgrade the next time. This is the assumption on which this tool was
> > designed.
>
> Erm, no the problem comes when you try to install a package and it breaks
> some other package. I am concerned about doing this because it will mess
> up the install phase and the ordering. Ideally the result after running
> Deity should be one with no uninstallable packages being installed. An
> uninstallable package is one that will cause another package to break or
> does not have it's own depends satisfied.
Yes, however, presumably deity won't have scheduled (or will have
prevented the user from scheduling) the installation of an uninstallable
package. What I'm saying is that if a package makes it through all our
checks and balances (i.e. all dependancies are met and it doesn't
conflict with anything, or it is replaced by something... yada yada
yada) then we should expect it not to break the system. If the user
overrides Deity's built in checks and installs an "uninstallable"
package then they deserve what they get.
What I'm saying is simply, Deity should do it's best to detect
uninstallable packages, but ultimately, if all these criteria are met,
it should be assumed that the package can be safely installed.
> There are even more cases where an autoupgrade can fail, the new version
> has a new dependancy that you don't have installed yet, the new version
> conflicts with a package you already have, etc.
I'm confused. Why would Deity be doing an auto-upgrade in these
circumstances. Surely these are all examples of uninstallable
packages. Have we not already discussed what to do in this cicumstance?
In the case of a new version having a new dependency, as long as that
package (that provides the dependancy) is available, you auto-mark that
for install too. That shouldn't be a problem.
> > I'm assuming that by your example there is no libreadline-dev being
> > installed at the same time that would fix this problem.
>
> Yes, there isn't a libreadline-deb avail or the one that would fix the
> problem isn't avail for automatic upgrade. This is not to say that it is
> impossible to install libreadline, only that it is impossible to do it
> without breaking the users rules for automatic upgrade.
>
> I'm thinking, libreadline is in hamm and wants to be auto upgraded to a
> newer hamm version. But libreadline-dev is in bo and cannot be auto
> upgraded. Autoupgrading libreadline would break the system and
> autoupgrading would violate the users wishes, the only option seems to be
> to put libreadline in keep. If the user really wants it installed (OR it
> becomes interrlated with some other thing the user wants to install) then
> libreadline-dev would be selected from hamm and libreadline would be
> upgraded.
>
> I guess, the general rule is that no automatic action (not initiated by
> the user) will break the system or violate the users preferences.
Precisely. I couldn't have said it better my self.
> This is in contrast with what we have talked about for auto install of
> deps in that the user initiates a request to install a program and the
> system considers a wider range of options to install the package.
I don't see the contrast. I have always been thinking along the lines
of the general rule you state above. I just think I didn't consider how
far a problem might go. (i.e. you have shown me a number of cases that
are far more complicated that I was imagining).
> Is that consistant with the rest of the features?
I think so.
> > I would grey out the install button and put a message in the status
> > window stating why it could not be auto installed. If the user fixes
> > the problem then the button can be ungreyed out.
>
> Do we want to mix auto-upgrade with auto-install? I have been treating
> them separately. Auto-upgrade is a gentile default action while
> auto-install is a more agressive user-initiated action.
They do have many similarities.
As far as implementation is concerned, I'm not particularly worried
whether they are mixed or seperate.
> Hm, let me just summarize...
>
> Stage 1 - Auto Upgrade - Automatically upgrade as many packages as
> possible without violating the users wishes. Do not install
> more packages, do not remove packages, do not upgrade to
> anything but the install-version and do not break any packages.
> Note - Packages with the auto flag set may be removed!
> Stage 2 - Auto Install - Installs packages because the user wished it to
> be so. It will install new packages, upgrade to versions other
> than 'install-version' but it will not remove packages.
> Note - Packages with the auto flag set may be removed!
> Stage 3 - Safe guard - Veto the install of anything that will break the
> system more than it already is.
>
> I think that summarizes my thoughts..
when are packages removed in here? (i.e. a user removed a package)
Am I understanding this correctly, in that this is the rough algorithm
that Deity will use to decide what to do, and make sure it doesn't break
the system?
Thanks,
Behan
--
Behan Webster mailto:behanw@verisim.com
+1-613-224-7547 http://www.verisim.com/
Reply to: