[opensuse-factory] [SOLVED] ssh-agent problems with XFCE / gnome-keyring-daemon
Hi all, After a TW update in the last few weeks, ssh with ssh-agent did no longer work with my established setup. (I did not verify the problem with a pristine user account, though). I have set up my system (a loooong time ago... ;)) so that the ssh key is stored somehow in gnome-keyring-daemon and gets unlocked upon login. The ssh-agent knows the key: seife@strolchi:~> ssh-add -l 1024 SHA256:96ejSSf7kXLZRWhEE4oJUk20+RukUpSJOu4elrVABCU seife@strolchi (RSA) ...but it did not work: seife@strolchi:~> ssh server sign_and_send_pubkey: signing failed: agent refused operation Password: If I now refreshed the agent with "ssh-add", and entered my passphrase, then ssh without password did work. The journal showed the following: Apr 08 18:28:41 strolchi gnome-keyring-daemon[1868]: the /usr/bin/ssh-add command failed: Child process exited with code 1 Apr 08 18:28:41 strolchi gnome-keyring-daemon[1868]: ssh_askpass: exec(/usr/lib/gcr-ssh-askpass): No such file or directory So the solution was to install the gcr-ssh-askpass package (which provides /usr/lib/gcr-ssh-askpass) and now everything is working as before. Hope this helps someone ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/08/2018 09:37 AM, Stefan Seyfried wrote:
So the solution was to install the gcr-ssh-askpass package (which provides /usr/lib/gcr-ssh-askpass) and now everything is working as before.
Hope this helps someone ;-)
Yes, it helped me. Thank you very much as non of the solutions I found Googling (disable Gnome Keyring etc) were very palatable. Thank you again for posting this! tony -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi all, https://bugzilla.opensuse.org/show_bug.cgi?id=1108381 reminds me of this problem. What is the best solution, or what are the differences from a users POV: * adding "packageand(gpg2:xfce4-session)" to Supplements: of gcr-ssh-askpass * adding "Recommends: gcr-ssh-askpass" to an XFCE pattern / package Or is there even a better way? Am 08.04.18 um 18:37 schrieb Stefan Seyfried:
Hi all,
After a TW update in the last few weeks, ssh with ssh-agent did no longer work with my established setup. (I did not verify the problem with a pristine user account, though).
I have set up my system (a loooong time ago... ;)) so that the ssh key is stored somehow in gnome-keyring-daemon and gets unlocked upon login.
[...]
So the solution was to install the gcr-ssh-askpass package (which provides /usr/lib/gcr-ssh-askpass) and now everything is working as before.
Hope this helps someone ;-)
-- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Sep 24, Stefan Seyfried wrote:
Hi all,
https://bugzilla.opensuse.org/show_bug.cgi?id=1108381 reminds me of this problem.
What is the best solution, or what are the differences from a users POV:
* adding "packageand(gpg2:xfce4-session)" to Supplements: of gcr-ssh-askpass
This means: gcr-ssh-askpass is needed if you have installed gpg2 and xfce4-session.
* adding "Recommends: gcr-ssh-askpass" to an XFCE pattern / package
This means, the XFCE pattern recommends to install gcr-ssh-askpass if available. This are two complete different things. From the bug report, one is clearly wrong and the recommends in the XFCE pattern is the correct fix. Thorsten
Or is there even a better way?
Am 08.04.18 um 18:37 schrieb Stefan Seyfried:
Hi all,
After a TW update in the last few weeks, ssh with ssh-agent did no longer work with my established setup. (I did not verify the problem with a pristine user account, though).
I have set up my system (a loooong time ago... ;)) so that the ssh key is stored somehow in gnome-keyring-daemon and gets unlocked upon login.
[...]
So the solution was to install the gcr-ssh-askpass package (which provides /usr/lib/gcr-ssh-askpass) and now everything is working as before.
Hope this helps someone ;-)
-- Stefan Seyfried
"For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 24.09.18 um 11:17 schrieb Thorsten Kukuk:
On Mon, Sep 24, Stefan Seyfried wrote:
Hi all,
https://bugzilla.opensuse.org/show_bug.cgi?id=1108381 reminds me of this problem.
What is the best solution, or what are the differences from a users POV:
* adding "packageand(gpg2:xfce4-session)" to Supplements: of gcr-ssh-askpass
This means: gcr-ssh-askpass is needed if you have installed gpg2 and xfce4-session.
Ok, so it will also get pulled in with "zypper dup --no-recommends". I'd actually like that. Because ssh is pretty broken in XFCE without it. gcr-ssh-askpass also already has "Supplements: packageand(gpg2:gnome-shell)"
* adding "Recommends: gcr-ssh-askpass" to an XFCE pattern / package
This means, the XFCE pattern recommends to install gcr-ssh-askpass if available.
This are two complete different things. From the bug report, one is clearly wrong and the recommends in the XFCE pattern is the correct fix.
But even if this is more correct, if the other one would work with sane (--no-recommends) settings, I'd actually prefer it (and make the same error the gnome packagers apparently did :-) Or am I still overlooking something? -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2018-09-24 at 11:26 +0200, Stefan Seyfried wrote:
Am 24.09.18 um 11:17 schrieb Thorsten Kukuk:
On Mon, Sep 24, Stefan Seyfried wrote:
Hi all,
https://bugzilla.opensuse.org/show_bug.cgi?id=1108381 reminds me of this problem.
What is the best solution, or what are the differences from a users POV:
* adding "packageand(gpg2:xfce4-session)" to Supplements: of gcr-ssh-askpass
This means: gcr-ssh-askpass is needed if you have installed gpg2 and xfce4-session.
Ok, so it will also get pulled in with "zypper dup --no-recommends". I'd actually like that. Because ssh is pretty broken in XFCE without it.
gcr-ssh-askpass also already has "Supplements: packageand(gpg2:gnome-shell)"
Supplements is a reverse recommends... both are ignored by --no- recommends (and using --no-recommends is not 'sane', just for the record; it is a deliberate choice to ignore recommendations by the packagers) Cheers, Dominique
On Mon, 24 Sep 2018 at 11:32, Dominique Leuenberger / DimStar <dimstar@opensuse.org> wrote:
On Mon, 2018-09-24 at 11:26 +0200, Stefan Seyfried wrote:
Am 24.09.18 um 11:17 schrieb Thorsten Kukuk:
On Mon, Sep 24, Stefan Seyfried wrote:
Hi all,
https://bugzilla.opensuse.org/show_bug.cgi?id=1108381 reminds me of this problem.
What is the best solution, or what are the differences from a users POV:
* adding "packageand(gpg2:xfce4-session)" to Supplements: of gcr-ssh-askpass
This means: gcr-ssh-askpass is needed if you have installed gpg2 and xfce4-session.
Ok, so it will also get pulled in with "zypper dup --no-recommends". I'd actually like that. Because ssh is pretty broken in XFCE without it.
gcr-ssh-askpass also already has "Supplements: packageand(gpg2:gnome-shell)"
Supplements is a reverse recommends... both are ignored by --no- recommends (and using --no-recommends is not 'sane', just for the record; it is a deliberate choice to ignore recommendations by the packagers)
Indeed, it is worth considering the upstream definition of 'Weak' dependencies (aka Recommends & Supplements) http://rpm.org/user_doc/dependencies.html "Weak: By default the dependency solver shall attempt to process the dependency as though it were strong. If this is results in an error then they should be ignored and not trigger an error or warning." In other words, recommends and suggests should be considered "installed by default, unless there is a blocking reason". I do not think it is "sane" to advocate for the use of --no-recommends in a great many cases. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown schrieb:
[...] "Weak: By default the dependency solver shall attempt to process the dependency as though it were strong. If this is results in an error then they should be ignored and not trigger an error or warning."
In other words, recommends and suggests should be considered "installed by default, unless there is a blocking reason".
I do not think it is "sane" to advocate for the use of --no-recommends in a great many cases.
Ack. However, I can see why people use --no-recommends. It would be worthwile to review the weak dependencies we have and make them smarter. For example perl recommends perl-doc. So by default one always ends up with perl-doc. Instead of that perl-doc could supplement the documentation pattern and perl. If all packages do that one could trigger installation of documentation with the pattern rather than individually for each package. Similarly many packages recommend their -lang package. Even though packages can provide locales. So the system pulls in localization packages only if a matching system language was selected. The recommends tag is not smart enough there. I'm sure many more cases could be found when taking a closer look. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Sep 24, Richard Brown wrote:
I do not think it is "sane" to advocate for the use of --no-recommends in a great many cases.
As long as packager recommends everything they like, even if nobody out there ever heard from it and will not use it even if installed, people will continue to use --no-recommends. In the old times we had the problem with too many Requires. Now we have the same problem, but only with too many Recommends. Recommends should only be used, if this adds functionality >> 80% of the users are really using it. And not like > 99,9% will never use it. I asked last week during a talk our Labs people, if one from them did ever heard of a functionality, which got installed in every Minimalsystem due to a recommends since > 5 years. Nobody ever heard of this. But due to the result (dependencys) of this, a lot of them install with --no-recommends ... Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2018-09-24 at 15:43 +0200, Thorsten Kukuk wrote:
Recommends should only be used, if this adds functionality >> 80% of the users are really using it. And not like > 99,9% will never use it.
I asked last week during a talk our Labs people, if one from them did ever heard of a functionality, which got installed in every Minimalsystem due to a recommends since > 5 years. Nobody ever heard of this. But due to the result (dependencys) of this, a lot of them install with --no-recommends ...
Yes, this is indeed a major problem. --no-recommends addresses the issue in short term for one usecase, but does not take care of all the other users. Just a typical example - where I think recommends makes sense, but it breaks for users of --no-recommends: Evince, a 'document viewer', has multiple backends. Traditionally, evince was used for displaying PDF and PS files (of which PS is even debatable). A couple more backends exist: comicdoc, tiff, xps, just to name the ones I know from head. None of them is strictly required for evince - as long as you don't open any such file type with it. Based on the history of the application, we, the packagers, set the PDF and PS engines as 'supplements: evince' (reverse, as it made more sense than evince recommending other packages in this case). This works as expected, and does what we want - but only as long as nobody goes --no-recommends. This just an example for iit takes thought' to know what to do - and -- no-recommends can harm the default user experience badly. I don't have a good recipe as to solve the underlying issue though: there is nothing the review could be asked to do, as deciding about this must be done by maintainers that actually understand the package indepth, and hopefully also have some insight about the use of the package. Of course, may might ask upstream - but they will just recommend 'everything their app can do, as that's what they wrote it for'. Cheers Dominique
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/09/2018 09.52, Dominique Leuenberger / DimStar wrote: > On Mon, 2018-09-24 at 15:43 +0200, Thorsten Kukuk wrote: >> Recommends should only be used, if this adds functionality >> >> 80% of the users are really using it. And not like > 99,9% will >> never use it. >> >> I asked last week during a talk our Labs people, if one from >> them did ever heard of a functionality, which got installed in >> every Minimalsystem due to a recommends since > 5 years. Nobody >> ever heard of this. But due to the result (dependencys) of this, >> a lot of them install with --no-recommends ... > > Yes, this is indeed a major problem. --no-recommends addresses the > issue in short term for one usecase, but does not take care of all > the other users. > > Just a typical example - where I think recommends makes sense, but > it breaks for users of --no-recommends: > > Evince, a 'document viewer', has multiple backends. Traditionally, > evince was used for displaying PDF and PS files (of which PS is > even debatable). > > A couple more backends exist: comicdoc, tiff, xps, just to name > the ones I know from head. > > None of them is strictly required for evince - as long as you > don't open any such file type with it. > > Based on the history of the application, we, the packagers, set the > PDF and PS engines as 'supplements: evince' (reverse, as it made > more sense than evince recommending other packages in this case). > > This works as expected, and does what we want - but only as long > as nobody goes --no-recommends. > > This just an example for iit takes thought' to know what to do - > and -- no-recommends can harm the default user experience badly. > > I don't have a good recipe as to solve the underlying issue > though: there is nothing the review could be asked to do, as > deciding about this must be done by maintainers that actually > understand the package indepth, and hopefully also have some > insight about the use of the package. Of course, may might ask > upstream - but they will just recommend 'everything their app can > do, as that's what they wrote it for'. - From a user/admin point of view, I have never enabled "no recommends", nor do I recommend doing it. However, the reason many people do it is that if they remove some package, the next time they run yast it may be automatically installed again. My workaround is to taboo those packages instead. Thus let me suggest to implement back the feature that would remember that the admin had uninstalled some thing that is recommended and not try to install it again automatically ;-) - -- Cheers / Saludos, Carlos E. R. (from openSUSE 15.0 (Legolas)) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCW6j99AAKCRC1MxgcbY1H 1St0AJ94ugDVCYjF/ahJs0Aja5NKj+uRAACfeDIcDvVXRd9IKw6W8qYPxUCY1Xk= =ic2t -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 24.09.18 um 15:52 schrieb Dominique Leuenberger / DimStar:
Evince, a 'document viewer', has multiple backends. Traditionally, evince was used for displaying PDF and PS files (of which PS is even debatable).
A couple more backends exist: comicdoc, tiff, xps, just to name the ones I know from head.
None of them is strictly required for evince - as long as you don't open any such file type with it.
I ran into this during the 42.2 => 42.3 updates on my family's machines. Evince was really useless because *no* plugin was installed afterwards :-) And still I prefer --no-r instead of accumulating random cruft with every update.
This works as expected, and does what we want - but only as long as nobody goes --no-recommends.
What works for me mostly is: fresh installation (which gets the recommends installed), then switch to "--no-r". Once every few years find something like the evince breakage and handle it. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2018-09-24 15:52, Dominique Leuenberger / DimStar wrote:
Evince, a 'document viewer', has multiple backends. Traditionally, evince was used for displaying PDF and PS files (of which PS is even debatable).
I don't have a good recipe as to solve the underlying issue [of recommended, but not required, plugins] though: there is nothing the review could be asked to do
It is just a matter of "communication", IMO. The user needs to be aware that a certain program has a plugin architecture and extra packages may be needed. zypper already does mention to the user if there are recommended packages (Just noticed ... half of the time!? bug report - https://github.com/openSUSE/zypper/issues/206 ) Just mentioning plugins in the package description is my current idea. (Done for evince.)
as deciding about this must be done by maintainers that actually understand the package indepth, and hopefully also have some insight about the use of the package. Of course, may might ask upstream - but they will just recommend 'everything their app can do, as that's what they wrote it for'.
Not always possible; some plugins for some software may be provided by a second party. Also of note: LibreOffice does just that, and they do it at a build level: they link, rather than dlopen, all their format "plugins". (Which also means a larger minimal installation because you can't get rid of support for 1980s file formats.) Coming back to the "communication" part: Libraries... Many programs, when using libraries, do a rather bad job of conveying precise error messages that indicate a missing codec/plugin is the problem rather than a broken file. (Ironically, /usr/bin/ffmpeg, using the ffmpeg libs, itself was such a candidate. That received a patch in openSUSE to be more vocal on the command line about deactivated codecs.) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24/09/2018 23:13, Thorsten Kukuk wrote:
On Mon, Sep 24, Richard Brown wrote:
I do not think it is "sane" to advocate for the use of --no-recommends in a great many cases.
As long as packager recommends everything they like, even if nobody out there ever heard from it and will not use it even if installed, people will continue to use --no-recommends.
In the old times we had the problem with too many Requires. Now we have the same problem, but only with too many Recommends.
Recommends should only be used, if this adds functionality >> 80% of the users are really using it. And not like > 99,9% will never use it.
I asked last week during a talk our Labs people, if one from them did ever heard of a functionality, which got installed in every Minimalsystem due to a recommends since > 5 years. Nobody ever heard of this. But due to the result (dependencys) of this, a lot of them install with --no-recommends ...
Thorsten
I somewhere have a bug / todo item to go through and remove all the Recommends from the minimal system, given that there is no way to install it with --no-recommends, therefore everything there is either required or not, when my current submission to patterns-base is accepted that will bring tumbleweed back in line with Leap / SLE, and after that there will be another round to tidy a few more things up. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Tuesday, 25 September 2018 0:16 Simon Lees wrote:
On 24/09/2018 23:13, Thorsten Kukuk wrote:
I asked last week during a talk our Labs people, if one from them did ever heard of a functionality, which got installed in every Minimalsystem due to a recommends since > 5 years. Nobody ever heard of this. But due to the result (dependencys) of this, a lot of them install with --no-recommends ...
I somewhere have a bug / todo item to go through and remove all the Recommends from the minimal system, given that there is no way to install it with --no-recommends, therefore everything there is either required or not, when my current submission to patterns-base is accepted that will bring tumbleweed back in line with Leap / SLE, and after that there will be another round to tidy a few more things up.
I don't disable automatic installation of recommended packages during the installation because patterns mostly use Recommends rather than Requires (which is good, patterns should IMHO only use Requires for really essential packages). But once the system is installed, I always set solver.onlyRequires = true solver.allowVendorChange = true to make the package management work the way I prefer. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 25/09/2018 14:53, Michal Kubecek wrote:
On Tuesday, 25 September 2018 0:16 Simon Lees wrote:
On 24/09/2018 23:13, Thorsten Kukuk wrote:
I asked last week during a talk our Labs people, if one from them did ever heard of a functionality, which got installed in every Minimalsystem due to a recommends since > 5 years. Nobody ever heard of this. But due to the result (dependencys) of this, a lot of them install with --no-recommends ...
I somewhere have a bug / todo item to go through and remove all the Recommends from the minimal system, given that there is no way to install it with --no-recommends, therefore everything there is either required or not, when my current submission to patterns-base is accepted that will bring tumbleweed back in line with Leap / SLE, and after that there will be another round to tidy a few more things up.
I don't disable automatic installation of recommended packages during the installation because patterns mostly use Recommends rather than Requires (which is good, patterns should IMHO only use Requires for really essential packages). But once the system is installed, I always set
solver.onlyRequires = true solver.allowVendorChange = true
to make the package management work the way I prefer.
Michal Kubecek
Its possible to just install the minimal or base pattern from the installer then install everything else later with --no-recommends (although currently you'll probably get some broken stuff). But because minimal and base have to always be installed it doesn't really make sense for them to recommend anything. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Tuesday, 25 September 2018 7:27 Simon Lees wrote:
Its possible to just install the minimal or base pattern from the installer then install everything else later with --no-recommends (although currently you'll probably get some broken stuff). But because minimal and base have to always be installed it doesn't really make sense for them to recommend anything.
That's what I used to do for servers, it would be too tedious for desktops (workstations). And after recent minimalization efforts, it's quite annoying even for servers or testing VMs. (I guess whoever tried to test something on SLE15 knows what I'm talking about.) In my case, it's not really about minimizing the installation footprint to the extreme. It's rather about making the package management behave in a sane way. Which for me means that, except for actual dependencies, I can uninstall a package and it stays out until I decide to install it. I don't really want to add locks for every other package I decide to uninstall. The same goes for solver.allowVendorChange. I fully understand why the default is false and I even agree that it's probably more useful that way for most users. But not for me so I'm always changing it. Michal Kubecek -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 24.09.18 um 11:31 schrieb Dominique Leuenberger / DimStar:
On Mon, 2018-09-24 at 11:26 +0200, Stefan Seyfried wrote:
Ok, so it will also get pulled in with "zypper dup --no-recommends". I'd actually like that. Because ssh is pretty broken in XFCE without it.
gcr-ssh-askpass also already has "Supplements: packageand(gpg2:gnome-shell)"
Supplements is a reverse recommends... both are ignored by --no- recommends
Ok, so technically it does not matter, and I can do recommends: in an XFCE pacakge without having anyone else involved.
(and using --no-recommends is not 'sane', just for the record; it is a deliberate choice to ignore recommendations by the packagers)
(OT) We can discuss this maybe at a future conference, for me (and some others I know), not using --no-r just makes regular updates unbearable. Something in between "Requires" and Recommends", that is "Requires" for zypper, but only recommends for RPM would be best, so that "Stuff you really should have to make it work" could be required harder than just recommends (evince-plugin-{ps,pdf}document comes to my mind), but still be uninstalled for some really minimal systems. IMHO too many package just recommend everything that could eventually be useful for someone, and if you always patch / dup with "--recommends", then the system inevitably grows every time by a significant amount. So something between "black" and "white" would be useful, granted, but we don't have that yet. Thanks for all the input! -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday, 24 September 2018 11:41 Stefan Seyfried wrote:
(OT) We can discuss this maybe at a future conference, for me (and some others I know), not using --no-r just makes regular updates unbearable. Something in between "Requires" and Recommends", that is "Requires" for zypper, but only recommends for RPM would be best, so that "Stuff you really should have to make it work" could be required harder than just recommends (evince-plugin-{ps,pdf}document comes to my mind), but still be uninstalled for some really minimal systems. IMHO too many package just recommend everything that could eventually be useful for someone, and if you always patch / dup with "--recommends", then the system inevitably grows every time by a significant amount. So something between "black" and "white" would be useful, granted, but we don't have that yet.
We have "Suggests", though, which is weaker than "Recommends". These are not installed by default even with the distribution default setting (which I always change right after each openSUSE installation). So we might want to keep only "reasonable" Recommends and demote the "you might also want" ones to Suggests. But that would be a lot of work and I'm afraid that packagers' view on what is worth to be marked as Recommends may be often more eager than what users would like. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24/09/2018 19:11, Stefan Seyfried wrote:
Am 24.09.18 um 11:31 schrieb Dominique Leuenberger / DimStar:
On Mon, 2018-09-24 at 11:26 +0200, Stefan Seyfried wrote:
Ok, so it will also get pulled in with "zypper dup --no-recommends". I'd actually like that. Because ssh is pretty broken in XFCE without it.
gcr-ssh-askpass also already has "Supplements: packageand(gpg2:gnome-shell)"
Supplements is a reverse recommends... both are ignored by --no- recommends
Ok, so technically it does not matter, and I can do recommends: in an XFCE pacakge without having anyone else involved.
(and using --no-recommends is not 'sane', just for the record; it is a deliberate choice to ignore recommendations by the packagers)
(OT) We can discuss this maybe at a future conference, for me (and some others I know), not using --no-r just makes regular updates unbearable. Something in between "Requires" and Recommends", that is "Requires" for zypper, but only recommends for RPM would be best, so that "Stuff you really should have to make it work" could be required harder than just recommends (evince-plugin-{ps,pdf}document comes to my mind), but still be uninstalled for some really minimal systems. IMHO too many package just recommend everything that could eventually be useful for someone, and if you always patch / dup with "--recommends", then the system inevitably grows every time by a significant amount. So something between "black" and "white" would be useful, granted, but we don't have that yet.
Thanks for all the input!
There is also http://bugzilla.suse.com/show_bug.cgi?id=1028028 which is a bug for just one of the probably many cases where patterns are broken if using --no-recommends. At the moment the way I see it, and the way that probably reflects the realities at the moment is something that is marked as recommends in most cases is something that is not essential but that the packager feels will make life better for most users. (Yeah there are probably still some things we can clean up), if someone then really doesn't want the recommended package for whatever reason they can remove it and lock it. The counter argument to this is users who complain when we don't recommend enough. The enlightenment pattern only used to recommend the things you needed to run enlightenment and several users complained that it didn't install enough stuff so now the pattern also installs a browser, media player and an office suite, because we also cater to users who want to do an installation and have a pretty much working system and not need to go pick a pdf viewer the first time they need to read a pdf and a picture viewer the first time they want to look at a jpg etc. As packagers we have to balance up both sides and come to something that will make most people happy. I don't think that adding something else between Requires, Recommends and Suggests is really going to fix that. How would it work? would it be an option users can select in the installer to "give me less packages" presuming users who want less are probably more advanced and will be better able to find understand and select that option then new users who we really should be given an out of the box functioning system. How do we document this new category for packagers? We then also have to deal with the fact we are now producing rpm's that other rpm based distro's won't be able to understand. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hello, On Sep 24 20:00 Simon Lees wrote (excerpt):
At the moment the way I see it, and the way that probably reflects the realities at the moment is something that is marked as recommends in most cases is something that is not essential but that the packager feels will make life better for most users.
What all the various individual packagers at openSUSE "feel" cannot lead to RPM dependencies that behave consistently for our end-users. See my reasoning https://lists.opensuse.org/opensuse-factory/2018-02/msg00924.html where I describe why I currently think - what RPM packages need to be installed to normally use the system for a particular use-case must be defined "outside" of the normal software packages (i.e. that must be defined only via patterns) - also recommended stuff cannot be defined via RPM recommends of normal software packages but recommended stuff must also be defined via patterns - in the end only RPM requirements are needed and RPM recommends are actually superfluous I got no response whether or not my above reasoning (you need to read my whole mail) is at least basically right or if I do perhaps misunderstand something. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 24/09/2018 21:15, Johannes Meixner wrote:
Hello,
On Sep 24 20:00 Simon Lees wrote (excerpt):
At the moment the way I see it, and the way that probably reflects the realities at the moment is something that is marked as recommends in most cases is something that is not essential but that the packager feels will make life better for most users.
What all the various individual packagers at openSUSE "feel" cannot lead to RPM dependencies that behave consistently for our end-users.
If we give them enough guidelines and info on how to make these decisions it probably can.
See my reasoning https://lists.opensuse.org/opensuse-factory/2018-02/msg00924.html where I describe why I currently think
- what RPM packages need to be installed to normally use the system for a particular use-case must be defined "outside" of the normal software packages (i.e. that must be defined only via patterns)
- also recommended stuff cannot be defined via RPM recommends of normal software packages but recommended stuff must also be defined via patterns
That would either require a huge number of additional patterns that we don't have or need right now, or alternatively a huge number of recommends becoming requires to in anyway have a reasonable system. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Hello, On Sep 24 22:07 Simon Lees wrote (excerpt):
On 24/09/2018 21:15, Johannes Meixner wrote:
On Sep 24 20:00 Simon Lees wrote (excerpt):
At the moment the way I see it, and the way that probably reflects the realities at the moment is something that is marked as recommends in most cases is something that is not essential but that the packager feels will make life better for most users.
What all the various individual packagers at openSUSE "feel" cannot lead to RPM dependencies that behave consistently for our end-users.
If we give them enough guidelines and info on how to make these decisions it probably can.
Even if that was possible, then only one single use case (the default) could be hardcocded via RPM dependencies, see my reasoning in https://lists.opensuse.org/opensuse-factory/2018-02/msg00924.html As far as I see it is currently not possible for a user to easily get a system installed that provides for example - all end everything that is useful to run a "web server" - the usual stuff for normal "printing" - only what is essential for "e-mail" without maunally specifying all individual RPM packages. I think this results all those issues when some users "feel" they need more in this area but less in that are while other users "feel" the opposite (less in this area but more in that area). Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/24/18 2:59 PM, Johannes Meixner wrote:
As far as I see it is currently not possible for a user to easily get a system installed that provides for example - all end everything that is useful to run a "web server" - the usual stuff for normal "printing" - only what is essential for "e-mail" without maunally specifying all individual RPM packages.
Given the fact that more and more "users" (also a blurry term) use config management of some sort I'd not consider this a big deal anymore and vote for minimal dependencies. Ciao, Michael.
On Mon, 2018-09-24 at 14:59 +0200, Johannes Meixner wrote:
- all end everything that is useful to run a "web server"
for this to work, you need to start with definining what is a 'web server'. Does it serve pure static content? Does it understand scripting languages? openSUSE should not try to cater to 'all possible variations of needs' - We can't but fail at that, as we would probably get as many different variations of 'need' as we have users. for this specific usecase we have the lamp_server pattern. Is this a web server? yes. Can it do more than many users will want? yes. Is it a good starting point for most users that are not fully aware of what they want? yes. (many in the last category will follow some tutorials on installing this and that) Of course, in this case, the 'problem' is solved via a pattern. But still, with one pre-tailored to a specific recommendation. As openSUSE we have to shine in proposing patterns as they make sense, without burrying users under them, making it impossible to pick the right one to get some work done in the end. Cheers Dominique
Hello, caution! long mail ;-) On Sep 24 15:07 Dominique Leuenberger / DimStar wrote (excerpt):
On Mon, 2018-09-24 at 14:59 +0200, Johannes Meixner wrote:
- all end everything that is useful to run a "web server"
for this to work, you need to start with definining what is a 'web server'. Does it serve pure static content? Does it understand scripting languages?
I am not at all an expert regarding "web server" but I think I know sufficiently about "printing" to be able to define three printing patterns - "printing-minmal" - "printing-recommended" - "printing-full" What nobody can do is to specify that via hardcoded RPM dependencies in the individual RPM packages. But I wonder how to define via RPM dependencies in other patterns what of those "printing-*" patterns should be installed by default but still let the user choose a different one, see below about my current thoughts.
openSUSE should not try to cater to 'all possible variations of needs'
This is not asked for because it is impossible. What I think is possible is an easier way for the users to specify which level of functionality they need individually in each one of their main usage areas.
... the 'problem' is solved via a pattern. But still, with one pre-tailored to a specific recommendation.
yes, 'a pattern' (i.e. a single pattern) can only define a single kind of use case.
As openSUSE we have to shine in proposing patterns as they make sense, without burrying users under them, making it impossible to pick the right one to get some work done in the end.
Currently openSUSE is burrying users who like to get a specific system as they need it under tons of individual RPMs. The current patterns have already some kind of tree structure. There are already top-level patterns like "Server" or "Gnome-desktop" or "KDE-desktop" and there are lower level patterns like "basic-system" or "Printing" or "LAMP server". I think with a better tree based pattern structure it would be easier for the user to specify what specific system he likes to get. The user would start to choose at the top-level patterns and only if needed go further down to whatever lower levels in his specific usage areas where he is interested in. For example usually (unless a user is specifically interested in a particular lower level area) no desktop system user should have to deal with what the "basic-system" is or what any infrastructure stuff like printing or mailing related patterns provide. In contrast a server system admin would in any case have to explicity specify what kind of services with what level of functionality he wants to have on his specific system. Only as offhanded example assume the top-level patterns are only "Desktop" and "Server". The "Server" pattern may have as next level patterns things like "Networking tools" "X11 server" "Web server" "Mail server" ... As an example I consider the "Desktop" pattern in more detail: The "Desktop" pattern may have as next level patterns like "Gnome desktop" "KDE desktop" "Xfce desktop" ... Each of those "<specific> desktop" patterns may have as next level "<specific> desktop minimal" "<specific> desktop recommended" "<specific> desktop full" Each of those "<specific> desktop <level>" patterns may have as next level "Web Browser" "Video and Audio" "Office software" "Printing" "E-mail" Each of those "<functionality>" patterns may have as next level "<functionality> minimal" "<functionality> recommended" "<functionality> full" Those "<functionality> <level>" patterns may finally require the normal RPM packages that provide the particular level of functionality. When the user chooses only the top-level "Desktop" pattern he should get a default desktop system installed i.e. the default desktop with its associated "<functionality> recommended" patterns that result the default set of normal RPM packages. On the other hand it must be possible for the user to change anything in that default selection as he likes. I wonder how to define that via RPM dependencies only in the patterns because the RPM dependencies in normal packages should only be RPM requirements for the essential stuff. Because the "Desktop" pattern must have a RPM requirement for one of the "Gnome desktop" "KDE desktop" "Xfce desktop" patterns it cannot require one of them directly because otherwise the user could not change what specific desktop gets installed (RPM recommends would be wrong because it is a fatal error when the "Desktop" pattern would not result that a desktop gets actually installed). I think the "Gnome desktop" "KDE desktop" "Xfce desktop" patterns must provide a common RPM capability e.g. named "specific_desktop" and the "Desktop" pattern requires "specific_desktop". Now I wonder how to define the default provider of that "specific_desktop" RPM capability. I am not a sufficient RPM expert to answer that question. I would hope the default provider could be specified by an artificial version of that "specific_desktop" RPM capability so that zypper would choose to install the pattern that provides the highest available version of the "specific_desktop" RPM capability. If this works things could even automatically behave well depending on what is available to be installed. E.g. assume "Gnome desktop" provides "specific_desktop version 100" "KDE desktop" provides "specific_desktop version 120" "Xfce desktop" provides "specific_desktop version 80" and all are available to be installed, then the "Desktop" pattern should result that KDE gets installed. When e.g. KDE would not be available to be installed, the "Desktop" pattern would still do "the right thing" and result that Gnome gets installed. I think in the end the problem is how to define the patterns reasonably well. I neither say it is easy nor it can be done quickly. But I think it is possible. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2018-09-24 12:30, Simon Lees wrote:
How do we document this new category [of RPM tags] for packagers? We then also have to deal with the fact we are now producing rpm's that other rpm based distro's won't be able to understand.
Been there, done that, no problem. Before reverse dependencies entered rpm, openSUSE carried it as a patch. Didn't really affect other distros other than when you tried to run rpmbuild. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (13)
-
Bernhard Voelker -
Carlos E. R. -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Johannes Meixner -
Ludwig Nussel -
Michael Ströder -
Michal Kubecek -
Richard Brown -
Simon Lees -
Stefan Seyfried -
Thorsten Kukuk -
Tony Jones