Bug 1138700

I should add that I *totally cannot reproduce this*, including with removing the version 32 packages and going back to 31 and trying again. But it definitely happened.

Hi, thanks for the report. I tried my best to reproduce it but DNF successfully upgraded from firefox-31.0-2.fc20.x86_64 and xulrunner-31.0-1.fc20.x86_64 to firefox-32.0-1.fc20.x86_64.rpm and xulrunner-32.0-1.fc20.x86_64.rpm. 
Can you attach solverdata [1] and exact packages (current version and upgraded version) when it occurs next time, please?

* BTW doing upgrade from install command is incorrect, it should ignore installed packages -> will be fixed in dnf.

[1] https://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/

Yes, I'll add more data if I can get a reproducer.

> * BTW doing upgrade from install command is incorrect, it should ignore installed packages -> will be fixed in dnf.

Hmmmm. If I understand what you're saying, that's potentially problematic in itself. What about the case where I have two packages, one an upgrade to an already-installed older version and one new? Do I have to `dnf install` one and `dnf upgrade` the other in two separate commands, or will there be a way to do both in one step? (And if it requires two steps, what happens if there is a circular relationship where the two new packages both require each other and the older version won't work?)

> Hmmmm. If I understand what you're saying, that's potentially problematic in
> itself. What about the case where I have two packages, one an upgrade to an
> already-installed older version and one new? Do I have to `dnf install` one
> and `dnf upgrade` the other in two separate commands, or will there be a way
> to do both in one step? (And if it requires two steps, what happens if there
> is a circular relationship where the two new packages both require each
> other and the older version won't work?)

While explicit mentioning of the not installed package won't itself trigger it's installation in this case, the depsolver can still see and decide to use the package to satisfy dependencies.

(In reply to Ales Kozumplik from comment #4)
> While explicit mentioning of the not installed package won't itself trigger
> it's installation in this case, the depsolver can still see and decide to
> use the package to satisfy dependencies.

So if the dependency can be resolved by some other package equally well (perhaps something in an enabled repository), that might get preferred over the one I just told it I want?

(In reply to Matthew Miller from comment #5)
> So if the dependency can be resolved by some other package equally well
> (perhaps something in an enabled repository), that might get preferred over
> the one I just told it I want?

Yes, but please understand that is a price of having the CLI behave consistently and predictably. If it would bother you very much submit a new bugzilla with a concrete case when it happens and attached depsolving data. [1] Thanks!

[1] http://dnf.baseurl.org/2013/11/25/reporting-depsolving-bugs/

Hmm,

OTOH, Jan, I think Matthew might be right and we might have done the wrong thing in dac3425: say the user specifies 'install foo-ver-rel.arch.rpm bar....' to be installed and another foo is already installed and bar is not. In the current upstream, the command will warn about skipping foo, do the transaction on bar and then exit with status 0. But the user did not get the system he specified on the command line, namely that the command will either fail or succeed with the foo package installed at the given version. So unless there is another angle to this you might see, we should consider reverting this patch.

Irrelevant of that, this current bug is probably good for closing as we have nothing to help us debug or reproduce the original problem.

I would just be careful with the wording here. I think that, according to the command's name, it should specify the *action* which should be taken and not the final *state*. I mean when the package foo-ver-rel.arch is already installed, the command should fail because it cannot *install* the package. Maybe we can introduce a new command for the state specification. Or just a '--skip-installed' switch. Or maybe that's what the kickstart plugin should do.

(In reply to Ales Kozumplik from comment #7)
> OTOH, Jan, I think Matthew might be right and we might have done the wrong
> thing in dac3425: say the user specifies 'install foo-ver-rel.arch.rpm
> bar....' to be installed and another foo is already installed and bar is
> not. In the current upstream, the command will warn about skipping foo, do
> the transaction on bar and then exit with status 0. But the user did not get
> the system he specified on the command line, namely that the command will
> either fail or succeed with the foo package installed at the given version.
> So unless there is another angle to this you might see, we should consider
> reverting this patch.

Still I see it as the right thing. Now it's more predictable behavior - it really does what command says not what user probably wanted. At least it does the same job as if you have selected foo remote package. It doesn't reinstall/upgrade/downgrade it either. Concerns about exit status of skipped/non-existing packages could solve [1].

Closing original bug report, discussion can continue.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1107737

dnf-0.6.2-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/dnf-0.6.2-1.fc21

I just hit this again. I _really_ want some sort of command that says "install the packages on the command line, regardless of whether or not an earlier version of some of them happen to be installed". It turns out that in building and testing updated RPMs, I do this all the time.

(In reply to Matthew Miller from comment #11)
> I just hit this again. I _really_ want some sort of command that says
> "install the packages on the command line, regardless of whether or not an
> earlier version of some of them happen to be installed". It turns out that
> in building and testing updated RPMs, I do this all the time.

Me too.

doing a 

dnf install /somedir/*.rpm

/somedir contains 3 freshly build rpms

one is a new version of a installed package
two requires one and in not installed
three requires one and in not installed

one is skipped because a previous version of one is installed
two & three is failing because the requirement of one is not fullfiled by the installed one

dnf update /somedir/*.rpm also fails, because two & three is not updates

So this is a big pain when building & testing packages.

I made some packaging error in rpms.

So dnf install /somedir/*.rpm will

skip one because it already install
install two
install three
update one, because it is required by two & three

So in this case it will work as expected, and how yum also works.

if one, two & three is installed in an earlier version then

dnf install /somedir/*.rpm will do nothing

yum install /somedir/*.rpm will update one,two & three

dnf update /somedir/*.rpm will work

yum install /somedir/*.rpm will always end up with all package install

dnf install /somedir/*.rpm will depend on the relationship between the packages what the result will be, not very consistant.

dnf should work as yum in this case, 

it should promote an install to an update
it should not reinstall, downgrade

Just as another comment... the rpm command has long supported -U (for upgrade) as "install if not installed, upgrade if it's an upgrade". You have to use -F (freshen) if you want "only do upgrades".

I guess it's okay to turn this around, but I would still like _some_ way to get the inclusive behavior. (Which I will then probably use all the time, because I can't think of a case when it's not what I want.)

Just an idea. I wonder whether "dnf --allowerasing install older-installed-ver-rel.arch" would make sense in this case.

(In reply to Radek Holy from comment #15)
> Just an idea. I wonder whether "dnf --allowerasing install
> older-installed-ver-rel.arch" would make sense in this case.

for this usecase it is newer or not installed local rpm's there is in play.

maybe an --allowupdating (with an option in dnf.conf to set it as default action)

or just make it default for install foobar.rpm to make it and upgrade if allready installed.

It is ok if install somename (from repo) is bailing out with somename is already installed, even if an update exist.

I think I've hit this one, although without globbing.  Trying to install an local rpm when an older version of the same is already present, I get:

    $ rpm -q dnf
       dnf-0.6.2-1.fc21.noarch
    $ rpm -q brewtarget
       brewtarget-2.0.2-3.fc21.x86_64
    $ ls *.rpm
       brewtarget-2.1.0-1.fc21.src.rpm
       brewtarget-debuginfo-2.1.0-1.fc21.x86_64.rpm
       brewtarget-2.1.0-1.fc21.x86_64.rpm
    $ sudo dnf --debugsolver install $PWD/brewtarget-2.1.0-1.fc21.x86_64.rpm
       Package brewtarget-2.0.2-3.fc21.x86_64 is already installed, skipping.
       Error: Nothing to do.

This isn't a niche developer case; there could be a user that, say, does not have a working networking connection but knows that an update of $package will fix it.  If there's some switch that makes this work, please turn it on by default; I can't imagine a situation where someone explicitly runs a command to install a newer locally-sourced RPM and is pleased when DNF refuses to do it.

DNF developers: this kind of change in behavior from yum (and for that matter rpm) is going to be painful and expensive for end users if we switch the default. If dnf is to be the default in F22, please prioritize user experience issues like this.

Pete, you have to do "upgrade" instead of "install" to make it work.

The coomand could be named "forceinstall".

Jan, the semantics are logical, but the behavior is unexpected.  I want to install *this specific package* - if dnf decides it is an upgrade transaction, fine; if it decides it is an install transaction, that's fine too.  As an end user, I'm not really interested in how the resolver has classified the transaction, I just want to install my package.  I strongly believe that dnf should know to set up the transaction as an upgrade, even if I use the 'install' command.  If a plugin makes it work, great, but let's please make sure it is enabled by default.  After many years of reinforcement, users *will* perceive this behavior as broken.

Pete, the thing is that you cannot *install* the package as is because it conflicts with another package. So, DNF can do one of these things:
* fail because you asked it to install the package but it cannot be installed;
* skip the package because a package of the same name is already installed (however I agree that in case of full NEVRA it does not make sense);
* do any possible magic to make the package installed;
* ask user what to do.
I believe that there are users that support every of the possible choices. We need to figure out what result is most expected as well as what is most consistent with the rest of DNF commands.

My personal opinion is that it should fail and with the "--allowerasing" (that I have already mentioned) it should do the magic.
That's how it works with "remote" packages (at least on my system) now and that wouldn't require yet another plugin.

Well, the condition for the skip does not necessarily be just the name of the package. I think it should be that the package can be skipped if there is already a package that provides the same *provide* because the command line arguments can represent also file provides etc.
Then IMHO the command should do the magic if the "--allowerasing" switch is on (as I have already said) or otherwise it should either fail or skip the argument (not sure what is better now) iff the condition above is true and iff the package cannot be installed.

(In reply to Matthew Miller from comment #18)
> DNF developers: this kind of change in behavior from yum (and for that
> matter rpm) is going to be painful and expensive for end users if we switch
> the default. If dnf is to be the default in F22, please prioritize user
> experience issues like this.

While I agree with you on prioritizing UX issues in general, I think we differ in the opinion on the impact this particular issue has. I can see why this is an unpleasant UX disruption for you. On the other hand you admitted yourself in comment 11 that this is not mainstream use case. I share this perspective, as I have never experienced the issue this bug is about.

Therefore I think having this functionality in a form of a plugin, switch or new command is quite sufficient.

(In reply to Radek Holy from comment #21)
> Pete, the thing is that you cannot *install* the package as is because it
> conflicts with another package.

This is a semantics thing. User wants this version of the package to become installed, possibly by upgrading an existing version.



(In reply to Jan Zeleny from comment #24)
> > DNF developers: this kind of change in behavior from yum (and for that
> > matter rpm) is going to be painful and expensive for end users if we switch
> > the default. If dnf is to be the default in F22, please prioritize user
> > experience issues like this.
> While I agree with you on prioritizing UX issues in general, I think we
> differ in the opinion on the impact this particular issue has. I can see why

Yes, I think we do differ. :) I think, particularly, that you are underestimating the impact of changing behavior from yum and from the RPM command line.

> this is an unpleasant UX disruption for you. On the other hand you admitted
> yourself in comment 11 that this is not mainstream use case. I share this
> perspective, as I have never experienced the issue this bug is about.

Reading back to comment 11, I don't think I said that at all. In fact, I said about about the opposite: it's something I hit all the time, and I'm pretty certain that it's something that our sysadmin users will also run into frequently.



> Therefore I think having this functionality in a form of a plugin, switch or
> new command is quite sufficient.

> Therefore I think having this functionality in a form of a plugin, switch or
> new command is quite sufficient.

It's better than nothing, but I hope we can make that command the new, advertised and documented default, because we really make our users unhappy when we ask them to adapt to change, and when it is really necessary, we should make sure that the reward we give them for doing that _really obvious_; in this case, it seems to be mostly about purity of terminology and I don't understand the user benefit.

When I am explicitly saying that I want to install some concrete version packages from the local files I probably want them installed and not skipped because internally it would be an update and not install. Especially when it is possible that I won't be able to install+update the packages in separate transactions due to new dependencies in these packages.

I'm sorry but you're really making user's life worse for some purity reasons.

The yum's behavior is perfectly logical as it won't do install of new package on 'update' command but install can do updates if explicit package is specified. Sometimes purity really stands against user-friendliness and I think we should not be stubborn puritans in such cases.

(In reply to Tomas Mraz from comment #27)
> When I am explicitly saying that I want to install some concrete version
> packages from the local files I probably want them installed

+1

I see your perspective and I kind of agree with you. Purity should not stand in a way of user friendliness. However if we make the code unnecessary complicated for a little increase of user friendliness in some corner case, that's where I would draw the line.

I guess what I want to say is: if this proves not to be a corner case that only a handful of people hit regularly, we will be open to reconsidering this.

(In reply to Jan Zeleny from comment #29)
> I guess what I want to say is: if this proves not to be a corner case that
> only a handful of people hit regularly, we will be open to reconsidering
> this.

Thanks Jan. That sounds reasonable. Do we have a good way of assessing or measuring that? I think in the past the approach has often been "throw it into Fedora and see if people react", and that contributes to a reputation as a painful distro for anyone actually trying to use it and keep up -- a reputation I'd like to balance a little bit. (We still want the cool new stuff like DNF, but we want to be _leading edge_, not _bleeding_.)

Here are some places where `yum install` is used this way:

 - http://fedoramagazine.org/shellshock-update-bash-packages-that-resolve-cve-2014-6271-and-cve-2014-7169-available/
 - http://kashyapc.com/2013/05/12/fetching-rawhide-kernel-builds-using-koji/
 - https://major.io/2014/04/07/openssl-heartbleed-updates-for-fedora-19-and-20/
 - http://lwn.net/Articles/593891/
 - http://fredlug.info/content/cve-2014-7169-updates-fedora

In a few minutes, I found user tutorials, forum posts, etc going back ten years that demonstrate the expectation that `yum install /path/to/package` works for both a new  %{name} and an upgrade to %{name}.  A lot of these examples use `yum localinstall`, sure, but install alone has long handled these commands the same way.

Besides the change in behavior, the semantics rankle me.  If you rip your shirt, I could hand you a different shirt and say "put on this shirt".  You wouldn't refuse and make me restate as "Put on this shirt instead of the shirt you are already wearing" because you know it would be silly to wear two shirts.  You also might be confused if I said "Upgrade this shirt", referring to the new shirt, when it is the *old* shirt that is in disrepair.

*** Bug 1160950 has been marked as a duplicate of this bug. ***

*** Bug 1169574 has been marked as a duplicate of this bug. ***

*** Bug 1175310 has been marked as a duplicate of this bug. ***

*** Bug 1179632 has been marked as a duplicate of this bug. ***

Install command in DNF would behave more or less the same as in yum with some switches added / changes in config file. All of that will be documented soon with all the differences between yum and DNF. According to that we will make consistent install command for packages from repo and packages specified by (local) url.

Tip of the day: add `--best` switch to use install as an upgrade if you don't put in any version of that package.

*** Bug 1190299 has been marked as a duplicate of this bug. ***

OK, these bugs are a complete chaos. If someone finds this, I think (s)he wouldn't bother to read all the comments to understand what is the real bug in the end. So, let me close this bug as we did originally and let's track the "install pkg == upgrade pkg" problem in bug 1160950 that is the first "duplicate" of this bug.

dnf-0.6.4-6.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update dnf'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-14323

dnf-0.6.4-7.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-9bcdcdc46b

dnf-0.6.4-7.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update dnf'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-9bcdcdc46b

dnf-0.6.4-7.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.