Bug 954143 - Leap (KDE5) doesn't know what to do with an .rpm file. Chrome 64bit and Skype tested.
Leap (KDE5) doesn't know what to do with an .rpm file. Chrome 64bit and Skype...
Status: CONFIRMED
: 1001262 (view as bug list)
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: YaST2
Leap 15.0
x86-64 openSUSE Factory
: P5 - None : Normal with 7 votes (vote)
: ---
Assigned To: Ancor Gonzalez Sosa
Jiri Srain
https://trello.com/c/tjc6qVDU
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-08 14:55 UTC by Jedi Beeftrix
Modified: 2021-02-18 15:08 UTC (History)
18 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jedi Beeftrix 2015-11-08 14:55:07 UTC
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0
Build Identifier: 

Downloaded the rpm from google for 64bit Chrome and tried to click on it.

Ark! Yast not even suggested, why?

So, I add Yast as the preferred option for .rpm files and click on it again.

Little Yast symbol pops up in a 'egg-timer' kind of way, few seconds later it disappears. Nothing.

So i load up Yast, select import, and point it at the rpm. Error message.

Is the whole problem because Leap is being clever and knows the 'opensuse' .rpm file is incompatible, or is this buggy behaviour?

Same thing happens with Skype i586 .rpm from MS.

Using 13.2 on my laptop i can open "apper software management" from the start menu.

However, on Leap a start menu search for "apper" finds nothing. Likewise, "open with" on file properties cannot locate apper in system or utilities.

Opening konsole in su and typing "run apper" gets nothing either...

Reproducible: Always

Steps to Reproduce:
1. download .rpm with "open with" (Yast) selected
2. open .rpm from download folder using Yast
3. open Yast, and "import" .rpm package from download folder
4. search for apper to use instead of Yast (nowhere to be found)
Actual Results:  
nothing. system does not currently do anything with an .rpm file.

Expected Results:  
.rpm opened with Yast, then proceeds to install using the Yast GUI 

Vanilla leap install working fine out the box, just can't modify it with new .rpm packages.
Comment 1 Ancor Gonzalez Sosa 2015-11-09 13:23:12 UTC
You should not add "YaST" as an option to manage rpms. You should add "Install/Remove Software".

The menu entry called "YaST" results in a call to
/usr/sbin/yast2
which is the generic YaST executable with no particular module (like software management).
In other words, running this in command line does nothing
/usr/sbin/yast2 mypackage.rpm

The entry called "Install/Remove Software" is the right one because it calls
/usr/sbin/yast2 sw_single
which is the YaST module which takes care of rpms and all that stuff.
In other words, running this in command line should do what you expect
/usr/sbin/yast2 sw_single mypackage.rpm

Moreover, as you can see in the dialog that pop-up the "import" option in the YaST package manager is targeted to package lists, not to individual rpms.

Last but not least, the absence of apper or the wrong filetype association in Plasma 5 are not YaST issues. Reassigning.
Comment 2 Wolfgang Bauer 2015-11-09 14:13:35 UTC
(In reply to Ancor Gonzalez Sosa from comment #1)
> Last but not least, the absence of apper or the wrong filetype association
> in Plasma 5 are not YaST issues. Reassigning.

Well, we removed apper from the default installation patterns as it is still a KDE4 application and the update notifier function doesn't work in Plasma5 (we use plasma5-pk-updates for that now).
You can still install apper manually though with YaST, it is still included in the distribution, and should add a file type association.

Installing Chrome won't work anyway though (without manually installing the package's key beforehand), as libzypp got stricter with signature verification and PackageKit won't handle that (that's already a problem in 13.2 with all updates installed).

One problem here IMHO is that YaST's .desktop file that contains such a file association for installing rpms has been removed in 13.2 (IIRC).
So depending how you look at it, it might also be seen as a YaST issue... ;-)
Comment 3 Martin Schlander 2015-11-12 20:00:39 UTC
It would definitely be great to have a file association for YaST sw_single for RPMs.

Since YaST is the canonical GUI package manager on SUSE. When Apper was used that lead some people to get confused and think Apper was the "recommended" package manager.
Comment 4 Ignacio Taranto 2015-11-13 01:10:18 UTC
I also experienced this issue on a Dell E6440 Laptop (Intel graphics).
I am using Leap 42.1 with a fresh install.

It happens either when rebooting or shutting down.

After that I got the following errors on dmesg:
[ [  185.369365] kactivitymanage[1461]: segfault at 7ff42f180d10 ip 00007ff42f3c469a sp 00007ffe3a55a608 error 4 in libQt5Sql.so.5.5.0[7ff42f3af000+3f000]

Switching to KDM lets me Reboot and Shutdown fine but the segfault persists.
Comment 5 Ignacio Taranto 2015-11-13 01:11:22 UTC
Disregard last comment it was meant for another bug. My Bad.
Comment 6 Marcelo Junior 2016-07-13 21:14:41 UTC
I simply modified /usr/share/applications/yast2-packager.desktop

I changed
NotShowIn=KDE;GNOME;MATE;
to
NotShowIn=GNOME;MATE;

Install/Remove Software now appears in KDE Menu and Open With dialog.
Comment 7 Fabian Vogt 2016-07-15 11:40:43 UTC
Reassigning to YaST2.
Could you re-enable the yast2-packager.desktop file for KDE (on Leap and TW)?
Installing an .rpm is an important task that should be an easy process with the GUI. The current state is very confusing for many.
Comment 8 Marcelo Junior 2016-07-15 14:25:59 UTC
I proposed a fix in https://github.com/yast/yast-packager/pull/171 once it get approved, i will patch 13.2 / 42.1 / TW.
Comment 9 Josef Reidinger 2016-07-28 10:16:35 UTC
Marcelo - patch looks ok for me, my only question is if you tested it as I do not have nor use KDE, so cannot verify it.
Comment 10 Fabian Vogt 2016-07-28 10:36:59 UTC
(In reply to Josef Reidinger from comment #9)
> Marcelo - patch looks ok for me, my only question is if you tested it as I
> do not have nor use KDE, so cannot verify it.

I tested the modification locally, works fine. Ark is somehow still the default, but at least it's easily to work around by using "Open With -> Install/Remove Software".
Comment 11 Josef Reidinger 2016-07-28 10:42:19 UTC
patch for TW merged. It will be also in Leap 42.2. I am not sure if it deserve maintenance update for 13.2 and 42.1
Comment 12 Fabian Vogt 2016-07-28 10:49:14 UTC
(In reply to Josef Reidinger from comment #11)
> patch for TW merged. It will be also in Leap 42.2. I am not sure if it
> deserve maintenance update for 13.2 and 42.1

I vote for an update for 42.1, but not 13.2 as that's still KDE 4 by default.
Comment 13 Wolfgang Bauer 2016-07-28 11:15:15 UTC
(In reply to Fabian Vogt from comment #10)
> Ark is somehow still the
> default, but at least it's easily to work around by using "Open With ->
> Install/Remove Software".

This could probably be fixed by adding a "InitialPreference=x" line to the .desktop file.

Ark has "InitialPreference=3", so x should be higher than 3.
Comment 14 Marcelo Junior 2016-07-28 13:48:31 UTC
I requested this fix in 42.1 and included "InitialPreference=10" too.
Worked pretty well, tested in a clean install.

https://build.opensuse.org/request/show/415613#
Comment 15 Josef Reidinger 2016-07-28 13:56:31 UTC
(In reply to Marcelo Junior from comment #14)
> I requested this fix in 42.1 and included "InitialPreference=10" too.
> Worked pretty well, tested in a clean install.
> 
> https://build.opensuse.org/request/show/415613#

Please do not create this direct maintenance fixes. We have infrastructure for it. Simple use git branch at github and after merge, it can be send as maintenance update. Otherwise it cause us trouble to keep it in sync with other maintenance updates. Keeping patches in git is much easier then in build service.

42.1 do not have own branch for packager, so one for SLE12 SP1 is used as documented in http://yastgithubio.readthedocs.io/en/latest/maintenance-branches/#maintenance-branch-naming

https://github.com/yast/yast-packager/tree/SLE-12-SP1
Comment 16 Marcelo Junior 2016-07-28 15:02:48 UTC
(In reply to Josef Reidinger from comment #15)
> Please do not create this direct maintenance fixes. We have infrastructure
> for it. Simple use git branch at github and after merge, it can be send as
> maintenance update. Otherwise it cause us trouble to keep it in sync with
> other maintenance updates. Keeping patches in git is much easier then in
> build service.

Thanks! Much better!

> 42.1 do not have own branch for packager, so one for SLE12 SP1 is used as
> documented in
> http://yastgithubio.readthedocs.io/en/latest/maintenance-branches/
> #maintenance-branch-naming
> 
> https://github.com/yast/yast-packager/tree/SLE-12-SP1

Ok.
Comment 17 Wolfgang Bauer 2016-09-26 19:25:26 UTC
(In reply to Marcelo Junior from comment #14)
> I requested this fix in 42.1 and included "InitialPreference=10" too.

The InitalPreference=10 still seems to be missing, could that be added too please?
See bug#1001262.
Comment 18 Wolfgang Bauer 2016-09-26 19:39:29 UTC
PS, just to be clear:
> (In reply to Marcelo Junior from comment #14)
> > I requested this fix in 42.1 and included "InitialPreference=10" too.
> 
> The InitalPreference=10 still seems to be missing, could that be added too
> please?
> See bug#1001262.

That is about 42.2.

AFAICS the change has not been submitted to 42.1 at all (yet?).
Comment 19 Marcelo Junior 2016-09-26 20:20:25 UTC
Hello Wolfgang Bauer!
the change was submitted but not approved yet.

Master branch (Allow open rpm)
https://github.com/yast/yast-packager/pull/171 (Approved)

Master branch (InitalPreference=10)
https://github.com/yast/yast-packager/pull/173 (Pending approbation)

42.1 (Allow open rpm and InitalPreference=10)
https://github.com/yast/yast-packager/pull/174 (Pending approbation)
Comment 20 Wolfgang Bauer 2016-09-26 20:44:21 UTC
(In reply to Marcelo Junior from comment #19)
> the change was submitted but not approved yet.

Ah ok.
Thank you for the information. (And thank you for taking care of this! ;-) )

I suppose we should mark bug#1001262 as duplicate then...
Comment 21 Wolfgang Bauer 2016-09-26 20:46:32 UTC
*** Bug 1001262 has been marked as a duplicate of this bug. ***
Comment 22 Mindaugas Baranauskas 2016-10-01 11:21:26 UTC
Note: this way with yast2-packager will not work with filenames containing space in path or filename. See https://bugzilla.suse.com/show_bug.cgi?id=1002417
Comment 23 Ancor Gonzalez Sosa 2016-10-03 14:19:44 UTC
I'm all for changing this for TW, SLE-12-SP2 and Leap 42.2.

I'm not sure whether it makes sense to release the "fix" for 42.1. It would be actually introducing a change in behavior, something not expected in a stable release. Maintenance updates are meant for real breakage or security problems, not to change the behavior (like file associations) to something more convenient.

Anyways, I will leave that for the maintenance team to decide (putting needinfo).

On the other hand, I trying to adapt to contributed fix to also handle the situation commented in comment#22. The solution suggested in that comment (introducing a new package including a script to handle the command line) looks a little bit overkill. I'm trying to fix it only in the desktop file. The desktop file as it is now in Tumbleweed works with Thunar (XFCE file manager) even if there are spaces, but not in Dolphin (KDE one).
Comment 24 Ancor Gonzalez Sosa 2016-10-04 08:16:12 UTC
This pull request should fix the problem, including bug#1002417. I want to merge it in the SLE-12-SP2/Leap 42.2 shared codebase. Since both are in beta stage I need the blessings from both release managers (setting needinfo).
https://github.com/yast/yast-packager/pull/190

For Leap 42.2 the benefit should be obvious.

For SLE-12-SP2 it should be harmless for Gnome and useful for customers installing KDE from packagehub.
Comment 25 Ancor Gonzalez Sosa 2016-10-04 12:17:36 UTC
We have reorganized the development branches to handle this kind of situations. I will adapt and re-target the pull request to go into Leap 42.2 ISO and to SLE-12-SP2 only as an maintenance update, so no need for SP2 release manager approval.

That change does not affect 42.1. As already said in comment#23, I would leave 42.1 out unless the maintenance team thinks different.
Comment 26 Andreas Stieger 2016-10-04 14:04:21 UTC
Not particularly hot on this for 42.1 maintenance as a separate update.
Comment 27 Ludwig Nussel 2016-10-04 14:24:36 UTC
What was the question for me here? If you ask me for my opinion I'd remove the feature completely. Users are supposed to install packages from well known repos and not download random software from the internet. If those who do that nevertheless can't rpm -i themselves, they obviously don't know what they are doing and we shouldn't help with that.
Comment 28 Adam Liebermann 2016-10-04 15:47:38 UTC
@Ludwig Nussel
I as a user am able to install via command line, but I have to check the command. 

What for? I know what I'm doing and sometimes I need to install a package from RPM (examples are missing Wifi driver on a laptop without ethernet, skype, mendeley, chrome..). Why making the live harder than need be?

It is those small things that make me as a user feel that I'm testing an unfinished product. please don't reject the patch :)
Comment 30 Pierre Bonamy 2016-11-21 21:29:30 UTC
@Ludwig Nussel
I think removing the feature entirely would be counter-productive regarding making the user aware of the risks. Users really wanting to install will find the command on the internet and just enter it, still without being aware of the risks.

I think if user safety is a concern, Yast should handle it the whole way and print a warning stating that installing RPM outside from openSUSE repos is risky (and of course, not supported by the community) when opening the RPM.

Given that, I'm in strong favour of applying the patch to avoid frustration for users knowing what they are doing. 

AFAICS, as of today, a fresh install of released Leap 42.2 still prioritise Ark over Yast to open RPMs. Does this mean it is too late for 42.2?
Comment 31 Fabian Vogt 2016-11-21 21:46:25 UTC
(In reply to Pierre Bonamy from comment #30)
> Given that, I'm in strong favour of applying the patch to avoid frustration
> for users knowing what they are doing. 
> 
> AFAICS, as of today, a fresh install of released Leap 42.2 still prioritise
> Ark over Yast to open RPMs. Does this mean it is too late for 42.2?

I'm in favor of a maintenance update here, this was obviously forgotten. However, this is the YaST team's decision.
Comment 32 Fabian Vogt 2018-01-31 09:28:12 UTC
(In reply to Ancor Gonzalez Sosa from comment #25)
> We have reorganized the development branches to handle this kind of
> situations. I will adapt and re-target the pull request to go into Leap 42.2
> ISO and to SLE-12-SP2 only as an maintenance update, so no need for SP2
> release manager approval.
> 
> That change does not affect 42.1. As already said in comment#23, I would
> leave 42.1 out unless the maintenance team thinks different.

It looks like this got completely forgotten for the master branches, so it is missing in Leap 15.x and Tumbleweed. Please fix.
Comment 33 Ancor Gonzalez Sosa 2018-01-31 11:50:18 UTC
(In reply to Fabian Vogt from comment #32)
> 
> It looks like this got completely forgotten for the master branches, so it
> is missing in Leap 15.x and Tumbleweed. Please fix.

If fact it was kind of "put to rest" because it was controversial, both from the implementation point of view and about how advisable would be to offer that "single click" approach.
Comment 34 Fabian Vogt 2018-01-31 14:51:10 UTC
(In reply to Ancor Gonzalez Sosa from comment #33)
> (In reply to Fabian Vogt from comment #32)
> > 
> > It looks like this got completely forgotten for the master branches, so it
> > is missing in Leap 15.x and Tumbleweed. Please fix.
> 
> If fact it was kind of "put to rest" because it was controversial, both from
> the implementation point of view and about how advisable would be to offer
> that "single click" approach.

Looks like there is a misunderstanding. YaST opens RPMs already, but if other applications can also open RPMs, they get run instead. This applies to file archivers for example.

This is obviously wrong so there shouldn't be any controversy around this.
Comment 35 Fabian Vogt 2018-02-05 09:16:42 UTC
(In reply to Fabian Vogt from comment #34)
> (In reply to Ancor Gonzalez Sosa from comment #33)
> > (In reply to Fabian Vogt from comment #32)
> > > 
> > > It looks like this got completely forgotten for the master branches, so it
> > > is missing in Leap 15.x and Tumbleweed. Please fix.
> > 
> > If fact it was kind of "put to rest" because it was controversial, both from
> > the implementation point of view and about how advisable would be to offer
> > that "single click" approach.
> 
> Looks like there is a misunderstanding. YaST opens RPMs already, but if
> other applications can also open RPMs, they get run instead. This applies to
> file archivers for example.
> 
> This is obviously wrong so there shouldn't be any controversy around this.

Ping?