Bug 1092822

Summary: zypper se suggests the use of zypper search-packages on Tumbleweed
Product: [openSUSE] openSUSE Tumbleweed Reporter: Richard Brown <rbrown>
Component: libzyppAssignee: Jiri Srain <jsrain>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Major    
Priority: P5 - None CC: behlert, dimstar, jsrain, lnussel, okurz
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Richard Brown 2018-05-10 17:11:26 UTC
When running zypper se on Tumbleweed it provides the following note

"Note: For an extended search including not yet activated remote resources please
use 'zypper search-packages'."

zypper search-packages does not work on openSUSE distributions and (very inappropriately) tries to use SCC libraries to contact SCC

"zypper search-packages jstest
Could not search for the package: SUSE::Connect::ApiError: 
No package found"

openSUSE's package manager should not be suggesting the use of SUSE's commercial customer platform. SUSE's SLE modules and any of the search tooling required for it should not be visible to openSUSE users.
Comment 1 Michael Andres 2018-05-14 12:21:20 UTC
The message is printed if a zypper-search-packages-plugin is offered in the distros repo.

If it's not appropriate for TW, why is it included?
Comment 2 Dominique Leuenberger 2018-05-14 12:32:34 UTC
(In reply to Michael Andres from comment #1)

> If it's not appropriate for TW, why is it included?

Heard of factory-first? Having a random package name's presence influence the output of zypper sounds strange
Comment 3 Dominique Leuenberger 2018-05-14 12:35:36 UTC
for TW, I don't mind removing the module, but that would mean SLE would have to handle it in a special way (@behlert?)

Alternatively, we could add

%if 0%{?is_opensuse}
ExclusiveArch: %nil
%endif

to the .spec file: then the source can be in openSUSE:Factory (and factory-first be followed), without the source being built in openSUSE distros.
Comment 4 Michael Andres 2018-05-14 14:11:23 UTC
(In reply to Dominique Leuenberger from comment #2)
> Heard of factory-first? Having a random package name's presence influence
> the output of zypper sounds strange

Required by bug#1089994. Otherwise zypper can restrict it to systems where the baseproduct CpeId matches "cpe:/o:suse:sle%02".
Comment 5 Richard Brown 2018-05-14 14:15:13 UTC
bug#1089994 is a SLE bug

I'm pretty darn sure that there was no intention for it to impact openSUSE in this way

There is no sense of having zypper-search-packages-plugin installed on openSUSE

It might make sense having it in the codebase for factory first, but it shouldn't be impacting users.
Comment 7 Michael Andres 2018-06-12 11:32:54 UTC
Stefan, Dominique: whom to assign it?
Comment 8 Stefan Behlert 2018-06-12 11:39:28 UTC
I'd say one of the maintainers - either zypp-maintainers@ or  the maintainer of the search-packages plugin. But as the text comes form the main package the first sounds more logical....
Comment 9 Michael Andres 2018-06-13 07:39:28 UTC
(In reply to Stefan Behlert from comment #8)
> I'd say one of the maintainers - either zypp-maintainers@ or  the maintainer
> of the search-packages plugin.

I thought the package should be removed from openSUSE (until maybe replaced by a version that fits the openSUSE eco system)? 

Would be the maintainer of the search-packages plugin (who? Jiří?) then.

> %if 0%{?is_opensuse}
> ExclusiveArch: %nil
> %endif


The zypper message is tied to the presence of the search-plugin. Zypper does not know (and does not want to know) whether it's running on openSUSE or SLE or whatever... 

Especially when printing the hint along with the help text, zypper knows little about the system (just whether "/usr/lib/zypper/commands/zypper-search-packages" is installed).

After all the trouble we had with this feature, I don't want to accidentally damage it. If zypper should suppress the message even if a search-packages plugin is present, I need a way to detect when (without knowing about repos and packages and confirmed (best by Kai Dupke) that this does not damage any of the intended usecases).
Comment 10 Michael Andres 2018-06-25 08:43:46 UTC
Reassigning to Vladimir. According to OBS you are maintainer and bugowner.

Would please you adapt the .spec file to prevent the package from being built in openSUSE distros, as suggesten in c#3 and c#6.