Bug 450208

I assume you have to use 'skip' during the install of the packages. What should 'ignore repo' do?

skip repo =

mark repo as ignored

foreach package in download list
  if package.repo is ignored
    skip package

----------------------

In the previous case I had to kill the yast, because I was about to upgrade KDE4 and since repo went dead I would have to skip each package from KDE4.

So, 'ignore repo' == 'skip all from this repo'

This is not a good idea, as you can end up with severly broken system afterwards and being unable to recover from that. You should abort installation at that point, disable the repo manually, and start the package selection again. To avoid this problem, you should refresh the repositories _before_ selecting _lots_ of packages in the package selector and then realizing you can't install them.

I would go for WONTFIX here.

Stanislav -- yes.

Jan -- you are of course for removing "skip" and "abort" as well. Because all arguments you gave hold for "skip"/"abort" too.

>  To avoid this problem, you should refresh the repositories _before_
> selecting _lots_ of packages in the package selector and then realizing you
> can't install them.

I always do this. And it does not solve the problem (by definition).

> This is not a good idea, as you can end up with severly broken system
> afterwards and being unable to recover from that.

Same for skip.

> You should abort installation

Same for abort.

> at that point, disable the repo manually, and start the package selection
> again. 

Maybe I know what I am doing and simply don't want to waste time to go through all the selecting, resolving conflicts, etc. ? Very likely.


There is no safe solution here, as long as Yast does not provide atomicy, rollback (already reported) and commit for whole operation or chunks of it. I could install 100 packages, 90th package will fail, I skip or abort and still end up with broken system.

"Skip all" is just helper (wrapper) for skip -- it does not provide lower or higher safety of operation. No magic bullet here -- if you insist on safety, rollback is the key, making installation more obscure and tiresome does not help.

(In reply to comment #5 from Maciej Pilichowski)
> Jan -- you are of course for removing "skip" and "abort" as well. Because all
> arguments you gave hold for "skip"/"abort" too.
> 
> >  To avoid this problem, you should refresh the repositories _before_
> > selecting _lots_ of packages in the package selector and then realizing you
> > can't install them.
> 
> I always do this. And it does not solve the problem (by definition).

Why? If the repo goes broken between the refresh and hitting 'Finish' to install the packages, then you just have bad luck. That's quite a corner-case. And skipping the failing packages won't make it any better for you.

> > You should abort installation
> 
> Same for abort.

No, if you abort at the very first 'can't get that package' error, you system is still in consistent state (putting aside circular dependencies). The packages are installed in correct order.

> > at that point, disable the repo manually, and start the package selection
> > again. 
> 
> Maybe I know what I am doing and simply don't want to waste time to go through
> all the selecting, resolving conflicts, etc. ? Very likely.
> 
> There is no safe solution here, as long as Yast does not provide atomicy,
> rollback (already reported) and commit for whole operation or chunks of it. I
> could install 100 packages, 90th package will fail, I skip or abort and still
> end up with broken system.
> 
> "Skip all" is just helper (wrapper) for skip -- it does not provide lower or
> higher safety of operation. No magic bullet here -- if you insist on safety,
> rollback is the key, making installation more obscure and tiresome does not
> help.

Agreed. And it is IMO not very useful - not much added value vs. work needed + risks.

And BTW, hitting Skip after apparent repository errors is not very wise => implementing a Skip All for this case is even less so => this is simply not a valid use case, don't you think?

> > >  To avoid this problem, you should refresh the repositories
> > > _before_ selecting _lots_ of packages in the package selector
> > > and then realizing you can't install them.
> >
> > I always do this. And it does not solve the problem (by
> > definition).
>
> Why? If the repo goes broken between the refresh and hitting
> 'Finish' to install the packages, then you just have bad luck.
> That's quite a corner-case. 

Not exactly -- for you -- maybe. For me -- very often. I often use wifi connection with AP that likes to break connection. 

The repo can be unavailable from the start, and it won't be disabled.

There are hundreds of cases (HDD out of space) that you can predict now and such also that you didn't anticipate. 

So it not wise to say -- oh well, this feature is dangerous, but it will be used only from time to time.

From my experience -- I see this dialog way to often. And I don't even keep track why repos are failing, I usually hit retry, but then skip. What can I do else?

> And skipping the failing packages won't 
> make it any better for you.

Jan, look, without rollback with yast there is _no_ safe solution.

Whatever you do -- skip/abort -- you are stuck. And it is your luck and your knowledge to recover from the situation.

So, the second this dialogs appears -- the user is in danger.

> > Same for abort.
> No, if you abort at the very first 'can't get that package' error,
> you system is still in consistent state (putting aside circular
> dependencies). The packages are installed in correct order.

Not at all. I can get half KDE4.1.2 and half KDE4.1.3. There is not atomic install in yast -- sequencing installs does not solve this.

> > "Skip all" is just helper (wrapper) for skip -- it does not
> > provide lower or higher safety of operation. No magic bullet here
> > -- if you insist on safety, rollback is the key, making
> > installation more obscure and tiresome does not help.
>
> Agreed. And it is IMO not very useful - not much added value vs.
> work needed + risks.

Again, the problem is this dialog appears. This is the fact. All what you can do is dangerous and at that point user is really on his/her own. If user does not know what is going on -- he/she ends up with a mess anyway. But if user knows what is going on -- why not give him/her a hand.

[ tex installation .......... *..... ] [ gimp installation .... ]

* here dialogs appear -- it is pretty sane for me to skip tex repo and jump to gimp.

I will get summary anyway, so I know what I should try to install again. But at least I get this gimp working right away.
text, gimp here are of course just examples.

> And BTW, hitting Skip after apparent repository
> errors is not very wise => implementing a Skip All for this case is
> even less so => this is simply not a valid use case, don't you
> think?

It is valid use because the button already exist. Wise -- depends of the user, dangerous -- sure. But there is no "safe" button there -- abort is dangerous as well.

You can add safety only but adding underlying layer -- committing chunks (or rollback in failure case).

Without "skip all" power-user has to abort (time) and waste time to do the exactly same thing that "skip all" would do -- but do it manually. Now -- what is the benefit? Users spends 10 minutes more and...?

Just to clarify -- I would like very much seeing rollback and commit -- this would really improve opensuse. Also undo install (reported, rejected). This is safety -- anything else are just workaround.

Another safe approach would be postpone mode -- download all, (resolve conflicts), install all.

So imho "skip all" is really needed, the problem is -- the other parts are missing :-)

I will report those ideas now.

Rollback and download->install order:
https://bugzilla.novell.com/show_bug.cgi?id=307714

Wontfix. So since safety is not valuable for yast, I will opt for having at least workaround such as "skip all" (however those reports are not related).

Download all, install all is planned (bug #398701, FATE #302159). So it seems we are finally in agreement and suggest to close this request and focus on FATE #302159 instead.

Now I am surprised -- if download all, install all is planned, than skip all makes more sense than now. Because I would be able to download what is downloadable now, skip all which are not, and then retry only those packages I had problems right before.

So why closing this report? -- it is great companion to the other one.