Re: [opensuse-factory] A users wishlist to make zypper up/dup & suse noob-friendly
snip
IMO, Tumbleweed is for experts :-)
- -- Cheers / Saludos,
Carlos E. R.
No it's not. I'm running it successfully and am far from an expert. Yes. It's for experienced users snip
Steven
Thank you very much Carlos, Dimstar, Dsant, Jim, Jimmy, Ken, Lars, Richard, Roman, Steven for your inputs. Summary ########## The above is valid: TW in its current form is for experts / experienced users / users following this list. That is exactly why I started this discussion: subject: "A users wishlist to make zypper up/dup & suse noob-friendly" See? I said implicitly that zypper is too complicated and my wish is, that it - or another update mechanism - would make TW beginner-friendly. And most of the improvements could also work for Leap, but that would be a side-effect. Results ########### a) on installation user opt-in to packman-repo => legaly not possible, however one suggestion was not yet commented: "There could be a supplementary screen : * If you live in US click here (open-sources repositories, DMCA ok...). * If you live in UK/Germany/Europe... click here (Packman repository added) [...] Dsant" b) default to packman priority 98 & auto vendor change => implementation possible through .repo parameter priority, but concerns about a race of lowest priorities & untested packages & not needing the whole repo. => solutions: - the noob does not know which subset of packman he needs to get multimedia working, thus just do the vendor change per default. - implement openQA also for packman to test & thus to allow automatical vendor change for this one repo only. - there is no race for lowest priority if only one repo==packman gets the 98 priority as the default. Can we agree that packman is the most important user repo of openSUSE so that it should be treated special? c) after adding packman do auto zypper dup or up with vendor change once: PackageKit / Apper cannot handle conflicts and thus is not supported in TW. => solutions: 1) enhance Apper to handle conflicts 2) automatizing zypper: noobs cannot use cron, nor command line / yast-gui, nor can they decide between "no / vendor change", "up / dup" => further comments: A users confirmation to install the automatically proposed update is desired, agreed. A password will be needed for new software only, as this is already the way PackageKit/Apper & Win7 (just tested) are doing it from user accounts. d) install recommends only once during installation as default, so that uninstalled apps do not come back => so far +1 for this e) I would update the whole wiki with the changes Thank you, thomas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 23 July 2015 at 10:46, Thomas Langkamp <langkamp@tomblog.de> wrote:
a) on installation user opt-in to packman-repo => legaly not possible, however one suggestion was not yet commented: "There could be a supplementary screen : * If you live in US click here (open-sources repositories, DMCA ok...). * If you live in UK/Germany/Europe... click here (Packman repository added)
My gut feeling is that this would still walk too close to the line regarding providing patent encumbered software, if not crossing it.
Can we agree that packman is the most important user repo of openSUSE so that it should be treated special?
I'm afraid I cannot. I can agree that Packman is an important repo for providing some patent encumbered packages. I have the highest respect for the work they're doing, but I have strong, often negative, opinions of the general quality of their packages, and therefore I cannot agree to the concept of treating it 'special'. Generally speaking, I trust a package from Packman no more than I would trust a random home: repo on OBS, which isn't very high. The openSUSE Project works hard to only provide tested software of a high quality. If we were to give external projects the kind of special treatment you're suggesting, they would need to at least meet those standards.
c) after adding packman do auto zypper dup or up with vendor change once: PackageKit / Apper cannot handle conflicts and thus is not supported in TW. => solutions: 1) enhance Apper to handle conflicts
Please remember that KDE is not the only desktop environment we have on offer, nor is it the only one that is a good choice for the beginners you are targeting with your efforts.
2) automatizing zypper: noobs cannot use cron, nor command line / yast-gui, nor can they decide between "no / vendor change", "up / dup" => further comments: A users confirmation to install the automatically proposed update is desired, agreed. A password will be needed for new software only, as this is already the way PackageKit/Apper & Win7 (just tested) are doing it from user accounts.
This is already done in GNOME with GNOME Software/PackageKit
d) install recommends only once during installation as default, so that uninstalled apps do not come back => so far +1 for this
For me you had a +1 for this _for servers & advanced users_, but a strong -1 for _desktops for beginners_. If you want a nice noob-friendly desktop, you shouldn't expect a beginner to know they have to install a whole bunch of optional packages, and just give them all to them at all the time. I'd argue that someone who cares about the presence of additional packages they don't need/use is by definition, not a beginner.
e) I would update the whole wiki with the changes
Thanks! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Can we agree that packman is the most important user repo of openSUSE so that it should be treated special?
I'm afraid I cannot. I can agree that Packman is an important repo for providing some patent encumbered packages.
some? Those are really important for desktop users. thats the reason why they were patented. If you want to watch videos (offline, non-flash) or hear music (except mp3) you most definetly need packman.
I have the highest respect for the work they're doing, but I have strong, often negative, opinions of the general quality of their packages,
can you elaborate on the quality? why this negative opinion?
Generally speaking, I trust a package from Packman no more than I would trust a random home: repo on OBS, which isn't very high.
so again - why not setup openQA also for packman? Nobody answered this yet. Is this an unreasonable request?
The openSUSE Project works hard to only provide tested software of a high quality.
true. TW is very stable thanks to openQA and all your hard work. but quality lies also in functionality and in this respect openSUSE lacks multimedia quality due to patents. Why do some other distros (ubuntu) do not have those problems? Do they pay?
c) after adding packman do auto zypper dup or up with vendor change once: PackageKit / Apper cannot handle conflicts and thus is not supported in TW. => solutions: 1) enhance Apper to handle conflicts
Please remember that KDE is not the only desktop environment we have on offer, nor is it the only one that is a good choice for the beginners you are targeting with your efforts.
gnome-software and muon also use PackageKit and also cannot handle conflicts. Apper was an example. Is there any chance that conflict-handling can be included in packagekit? What are the other choices you mention? yast-gui is not it, is it?
2) automatizing zypper: noobs cannot use cron, nor command line / yast-gui, nor can they decide between "no / vendor change", "up / dup" => further comments: A users confirmation to install the automatically proposed update is desired, agreed. A password will be needed for new software only, as this is already the way PackageKit/Apper & Win7 (just tested) are doing it from user accounts.
This is already done in GNOME with GNOME Software/PackageKit
what exactly. automatic updates for TW on Gnome are working and enabled? Even if zypper is the only recommended update/upgrade method for TW? if so, great! Then lets activate apper for KDE TW again, it is not activated per default, nor working, nor recommended now. Nor does it handle conflicts.
d) install recommends only once during installation as default, so that uninstalled apps do not come back => so far +1 for this
For me you had a +1 for this _for servers & advanced users_, but a strong -1 for _desktops for beginners_.
If you want a nice noob-friendly desktop, you shouldn't expect a beginner to know they have to install a whole bunch of optional packages, and just give them all to them at all the time.
I'd argue that someone who cares about the presence of additional packages they don't need/use is by definition, not a beginner.
ok, good point. did not see it that way. we can erase this one from my list :D
e) I would update the whole wiki with the changes
Thanks!
welcome. cheers, tomme -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-07-28 at 10:34 +0200, Thomas Langkamp wrote:
Can we agree that packman is the most important user repo of openSUSE so that it should be treated special?
I'm afraid I cannot. I can agree that Packman is an important repo for providing some patent encumbered packages.
some? Those are really important for desktop users. thats the reason why they were patented. If you want to watch videos (offline, non-flash) or hear music (except mp3) you most definetly need packman.
No, you don't... you could actually go the patent-legal way and buy the OnePlay Codec Pack... stating that you must use PM is like stating you must commit a crime to use watch Videos (depending on region that is... )
so again - why not setup openQA also for packman? Nobody answered this yet. Is this an unreasonable request?
That's something the packman team would have to organize. Note that PM is not provided by the openSUSE project... so asking about improvements on the packman infrastructure here is probably about as useful as asking Apple to improve the openSUSE infrastructure... they are just disjoint.
true. TW is very stable thanks to openQA and all your hard work. but quality lies also in functionality and in this respect openSUSE lacks multimedia quality due to patents. Why do some other distros (ubuntu) do not have those problems? Do they pay?
They have their corporate headquarter on Cayman ilands.. try to sue them.. and you'll fail in many ways :)
gnome-software and muon also use PackageKit and also cannot handle conflicts. Apper was an example. Is there any chance that conflict-handling can be included in packagekit?
The 'problem' here is that PK was not designed for a full user -interaction, but it relies on proper repositories - something other distros have less trouble to offer (as they do not use OBS, making it so easy to create additional, conflicting repositories)
=> further comments:
A users confirmation to install the automatically proposed update is desired, agreed. A password will be needed for new software only, as this is already the way PackageKit/Apper & Win7 (just tested) are doing it from user accounts.
This is already done in GNOME with GNOME Software/PackageKit
what exactly. automatic updates for TW on Gnome are working and enabled?
No, that referred to the password not being needed for updates. gnome -software does download the updates in the background, but does not apply them without user action (one possible action is the tickbox on shutdown: apply system update (screenshot pasted at http://paste.opensuse.org/51189139 for your reference)
For me you had a +1 for this _for servers & advanced users_, but a strong -1 for _desktops for beginners_.
If you want a nice noob-friendly desktop, you shouldn't expect a beginner to know they have to install a whole bunch of optional packages, and just give them all to them at all the time.
I'd argue that someone who cares about the presence of additional packages they don't need/use is by definition, not a beginner.
ok, good point. did not see it that way. we can erase this one from my list :D
Packagers should be more aware of the distinction between recommended and suggested packages: - Recommended: automatically installed, greatly enhances the capability of the package. Even if it could work without this feature, it is impaired - Suggested: a functional enhancement. The user should be aware that the feature is provided, but for normal operation of a package, this is not needed. The 'suggests' might need to be better exposed in YaST Software Manager though... Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
Am 28.07.2015 um 10:58 schrieb Dimstar / Dominique Leuenberger:
On Tue, 2015-07-28 at 10:34 +0200, Thomas Langkamp wrote:
Can we agree that packman is the most important user repo of openSUSE so that it should be treated special?
I'm afraid I cannot. I can agree that Packman is an important repo for providing some patent encumbered packages.
some? Those are really important for desktop users. thats the reason why they were patented. If you want to watch videos (offline, non-flash) or hear music (except mp3) you most definetly need packman.
No, you don't... you could actually go the patent-legal way and buy the OnePlay Codec Pack... stating that you must use PM is like stating you must commit a crime to use watch Videos (depending on region that is... )
OK. then we need a desktop-button / link advertising this solution. Is that an option? Many years I did not even know that such a solution existed. If it is not an option we are back at point zero I am afraid.
so again - why not setup openQA also for packman? Nobody answered this yet. Is this an unreasonable request?
That's something the packman team would have to organize. Note that PM is not provided by the openSUSE project... so asking about improvements on the packman infrastructure here is probably about as useful as asking Apple to improve the openSUSE infrastructure... they are just disjoint.
the infrastructure is disjoint - but don´t we share some common goals as both work on opensuse packages / improving the distro? not helpful to compare this to apple. packamn deserves better. If there would be interest to push multimedia on opensuse, some openQA devs could propose openQA to packman and offer them help. But it seems that there is no interest here. If I alone go to the packman team and say: hey, please setup openQA for me, opensuse devs are not interested, but me, I am - then I already know their answer: "We have no hardware for this, no money to buy, nor man-power nor knowledge how to do it. You have to do it yourself... or ask suse" Packman-Team is known to have not enough devs / funds / hardware.
true. TW is very stable thanks to openQA and all your hard work. but quality lies also in functionality and in this respect openSUSE lacks multimedia quality due to patents. Why do some other distros (ubuntu) do not have those problems? Do they pay?
They have their corporate headquarter on Cayman ilands.. try to sue them.. and you'll fail in many ways :)
ok, wow. just wow. thanks for the information. very interesting.
gnome-software and muon also use PackageKit and also cannot handle conflicts. Apper was an example. Is there any chance that conflict-handling can be included in packagekit?
The 'problem' here is that PK was not designed for a full user -interaction, but it relies on proper repositories - something other distros have less trouble to offer (as they do not use OBS, making it so easy to create additional, conflicting repositories)
=> further comments:
A users confirmation to install the automatically proposed update is desired, agreed. A password will be needed for new software only, as this is already the way PackageKit/Apper & Win7 (just tested) are doing it from user accounts.
This is already done in GNOME with GNOME Software/PackageKit
what exactly. automatic updates for TW on Gnome are working and enabled?
No, that referred to the password not being needed for updates. gnome -software does download the updates in the background, but does not apply them without user action (one possible action is the tickbox on shutdown: apply system update (screenshot pasted at http://paste.opensuse.org/51189139 for your reference)
very nice to see this. And this works ok for TW despite being not recommended for it? Ok, then I will have to open a feature request for plasma5 to add such functionality for apper, muon. But then apper is still not working nor recommended for TW.
For me you had a +1 for this _for servers & advanced users_, but a strong -1 for _desktops for beginners_.
If you want a nice noob-friendly desktop, you shouldn't expect a beginner to know they have to install a whole bunch of optional packages, and just give them all to them at all the time.
I'd argue that someone who cares about the presence of additional packages they don't need/use is by definition, not a beginner.
ok, good point. did not see it that way. we can erase this one from my list :D
Packagers should be more aware of the distinction between recommended and suggested packages: - Recommended: automatically installed, greatly enhances the capability of the package. Even if it could work without this feature, it is impaired - Suggested: a functional enhancement. The user should be aware that the feature is provided, but for normal operation of a package, this is not needed.
The 'suggests' might need to be better exposed in YaST Software Manager though...
Cheers, Dominique
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-07-28 at 11:28 +0200, Thomas Langkamp wrote:
No, you don't... you could actually go the patent-legal way and buy the OnePlay Codec Pack... stating that you must use PM is like stating you must commit a crime to use watch Videos (depending on region that is... )
OK. then we need a desktop-button / link advertising this solution. Is that an option? Many years I did not even know that such a solution existed. If it is not an option we are back at point zero I am afraid.
Sorry, I'm again talking a bit GNOME-way here. In totem, when you play a file that we do not have a codec for, you get a prompt like this one: http://paste.opensuse.org/46984118 following through the notification, gnome-software is started, which in the current case presented itself like: http://paste.opensuse.org/53994650 (note: I intentionally removed the codec packs from my machine to reproduce this, and there is no PM or alternative repo with GStreamer codecs enabled) Note the 2nd entry: MPEG-4 AAC Decoder not found, which has a link to the following website: https://software.opensuse.org/codecs, where the first option proposed is the legal codec pack by Fluendo (now actually OnePlay, seems the link no longer works.. will get this fixed asap) You should be redirected to http://www.oneplaydirect.com/all_oneplay_products/
That's something the packman team would have to organize. Note that PM is not provided by the openSUSE project... so asking about improvements on the packman infrastructure here is probably about as useful as asking Apple to improve the openSUSE infrastructure... they are just disjoint.
the infrastructure is disjoint - but don´t we share some common goals as both work on opensuse packages / improving the distro? not helpful to compare this to apple. packamn deserves better.
There are members from the openSUSE community maintaining Packman infra.. but it can't be 'the openSUSE project' and especially not SUSE as the main sponsor of the project, as this, again, would lead to legal implications.
If there would be interest to push multimedia on opensuse, some openQA devs could propose openQA to packman and offer them help.
If it's about setting up openQA, I'm sure the devs are willing to assist and guide. They helped RedHat/Fedora set up an infra...
But it seems that there is no interest here. If I alone go to the packman team and say: hey, please setup openQA for me, opensuse devs are not interested, but me, I am - then I already know their answer: "We have no hardware for this, no money to buy, nor man-power nor knowledge how to do it. You have to do it yourself... or ask suse"
The hardware will be the main concern - if there are no workers to run the test, you're doomed. The instal / setup of openQA could certainly be helped with
Packman-Team is known to have not enough devs / funds / hardware.
Again, nothing 'the openSUSE project' can really change without walking into the deep waters.
No, that referred to the password not being needed for updates. gnome -software does download the updates in the background, but does not apply them without user action (one possible action is the tickbox on shutdown: apply system update (screenshot pasted at http://paste.opensuse.org/51189139 for your reference)
very nice to see this. And this works ok for TW despite being not recommended for it? Ok, then I will have to open a feature request for plasma5 to add such functionality for apper, muon. But then apper is still not working nor recommended for TW.
It works reasonably well, and is in fact how I update my TW setup most of the times. There is one issue I'm aware of (there are surely more): if a package asks for a license (like flash-player does), then the offline update, which is completely non-interactive, can't handle it yet. Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
On Tue, 2015-07-28 at 10:58 +0200, Dimstar / Dominique Leuenberger
They have their corporate headquarter on Cayman ilands.. try to sue them.. and you'll fail in many ways :)
Correction, it used to be Isle of Men (not cayman).. but according to current info found, it's now actually UK based (London), incl. an office in the US. So it could be indeed interesting to understand how they manage that (from what I gather, Canonical entered a license agreement deal with MPEG-LA in 2010, see http://www.omgubuntu.co.uk/201 0/05/canonical-licenses-h264-theora-out-for-the-count-updated; yet, Canonical is not listed on the patent holders in good standing on http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx, indicating that they might no longer have it covered - and in fact the coverage wasa merely for OEM's pre-installing Ubuntu on machines, not for 'users getting the install sources from the web). yet, I think we should their lawyers care for their product, while we have our sponsor's legal department take care of 'ours' -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-28 10:58, Dimstar / Dominique Leuenberger wrote:
Packagers should be more aware of the distinction between recommended and suggested packages: - Recommended: automatically installed, greatly enhances the capability of the package. Even if it could work without this feature, it is impaired - Suggested: a functional enhancement. The user should be aware that the feature is provided, but for normal operation of a package, this is not needed.
It would be better if applications, when the user tried to use a feature that lacks those extra packages, would at least hint what exact extra packages are missing. Even perhaps trigger yast on a click with those packages selected. I know, I know, I can't imagine how to do this. Quite difficult. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW3ezwACgkQja8UbcUWM1waggD/W4WlCzRa0LIVhi9OHC7GzUEc RmsKbwcgKU0GCTpjmH4BAJb9ZWF1XEEJ89cu3Nm+kEgPdw/oVNvDIepRup+FQHce =f5ef -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-07-28 at 14:53 +0200, Carlos E. R. wrote:
It would be better if applications, when the user tried to use a feature that lacks those extra packages, would at least hint what exact extra packages are missing. Even perhaps trigger yast on a click with those packages selected.
Carlos, please read my follow-up mail in this thread, which explains what totem (the GNOME Video Player) already does in combination with PackageKit/GNOME-Software. If a codec is missing, PK is instructed to find the feature. If it's available in a repo, it will be proposed for installation... if it's not found, it wouldn't help to show a random package name (which would be a wild guess). In the case of missing codecs, gnome-software instructs the user further with a web link. Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
On Tue, 2015-07-28 at 14:57 +0200, Dimstar / Dominique Leuenberger wrote:
On Tue, 2015-07-28 at 14:53 +0200, Carlos E. R. wrote:
It would be better if applications, when the user tried to use a feature that lacks those extra packages, would at least hint what exact extra packages are missing. Even perhaps trigger yast on a click with those packages selected.
Carlos,
please read my follow-up mail in this thread, which explains what totem (the GNOME Video Player) already does in combination with PackageKit/GNOME-Software.
If a codec is missing, PK is instructed to find the feature. If it's available in a repo, it will be proposed for installation... if it's not found, it wouldn't help to show a random package name (which would be a wild guess). In the case of missing codecs, gnome-software instructs the user further with a web link.
oh, to make the conclusion out of this: all the stuff is already there in the distribution and proven to work. The fact that a lot of apps don't make use of the infrastructure is a different topic. -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-28 14:57, Dimstar / Dominique Leuenberger wrote:
On Tue, 2015-07-28 at 14:53 +0200, Carlos E. R. wrote:
It would be better if applications, when the user tried to use a feature that lacks those extra packages, would at least hint what exact extra packages are missing. Even perhaps trigger yast on a click with those packages selected.
Carlos,
please read my follow-up mail in this thread, which explains what totem (the GNOME Video Player) already does in combination with PackageKit/GNOME-Software.
Yes, I saw that a minute later. Yes, that's the way to do it. However, I was not thinking of multimedia, but rather of any package installation. There are mandatory dependencies which have to be installed, but there are recommends that can be ignored. Later, perhaps months later, when you try to use some feature of that package you notice it does not work. It would be nice if it were possible to automatically suggest that instant to install what is missing, instead of fail with missing symbol or some other cryptic message. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW3foUACgkQja8UbcUWM1zLjgD/aOaC1FBSyFRXGERjm6ldO+89 NkJn8dgEYySUEWcfGjMA/1cyEfXJMo28hkoUEwqwzlKBIiNxCo4h9LHlj9QdrTtN =EQTT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-07-28 at 15:07 +0200, Carlos E. R. wrote:
On 2015-07-28 14:57, Dimstar / Dominique Leuenberger wrote:
On Tue, 2015-07-28 at 14:53 +0200, Carlos E. R. wrote:
It would be better if applications, when the user tried to use a feature that lacks those extra packages, would at least hint what exact extra packages are missing. Even perhaps trigger yast on a click with those packages selected.
Carlos,
please read my follow-up mail in this thread, which explains what totem (the GNOME Video Player) already does in combination with PackageKit/GNOME-Software.
Yes, I saw that a minute later. Yes, that's the way to do it.
However, I was not thinking of multimedia, but rather of any package installation. There are mandatory dependencies which have to be installed, but there are recommends that can be ignored.
Later, perhaps months later, when you try to use some feature of that package you notice it does not work. It would be nice if it were possible to automatically suggest that instant to install what is missing, instead of fail with missing symbol or some other cryptic message.
Indeed, I could imagine some cases where this could work - the 'problem' is that in most cases we're talking about extensions/plugins.. of which an infinite number can exist. The main application has generally no way of knowing what can be possible. so, if this were to be done, the app would need to have a 'specific' way to 'name' possible features, and the package a specific way to provide this (in multimedia packages this is done with a provides in the form gstreamer1(decoder-video/mpeg)(mpegversion=4) for example). For evince (which is extensible by modules) I could imagine it to query the package manager by evince(application/pdf) when the pdf module is missing (as an example). This, as opposed to the current error message Unable to open document “file:///path/to/document.pdf”. File type PDF document (application/pdf) is not supported This is currently not implemented, but would likely be rather trivial (with the packagekit dbus api). I guess that's the direction you meant to lead to, right? Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-28 15:24, Dimstar / Dominique Leuenberger wrote:
I guess that's the direction you meant to lead to, right?
Yes :-) I don't have an actual example in mind, but... let me see if I can explain. In 13.1 you can remove packages, and they remain off. Since 13.2, yast wants to install them back the next time you run it, because they are recommended by something. So the recommendation is either to taboo what the user removes, or to overall disable "install recommended packages for installed packages" or similar wording (13.1 somehow remembers: this feature had problems and was removed in 13.2). The problem arises when they try to use, from an application, something that was not installed (although recommended), and it is difficult from the application to know what package is needed on package management. On an ideal world, the application could trigger /then/ the installation of the recommended packages. It doesn't need to be plugins, but that's one, yes. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW3hvwACgkQja8UbcUWM1xhogD/VDuG2fPXwAUhfszBVHtgiTjB hP+qKvOY16rYvcMEuOABAJdbuTfuK5GKFS7fs9ZSTPIIb8fVw3SplYiLUFAPtTdl =UZr/ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-07-28 at 15:43 +0200, Carlos E. R. wrote:
On 2015-07-28 15:24, Dimstar / Dominique Leuenberger wrote:
I guess that's the direction you meant to lead to, right?
Yes :-)
I don't have an actual example in mind, but... let me see if I can explain.
In 13.1 you can remove packages, and they remain off. Since 13.2, yast wants to install them back the next time you run it, because they are recommended by something. So the recommendation is either to taboo what the user removes, or to overall disable "install recommended packages for installed packages" or similar wording (13.1 somehow remembers: this feature had problems and was removed in 13.2).
The problem arises when they try to use, from an application, something that was not installed (although recommended), and it is difficult from the application to know what package is needed on package management.
On an ideal world, the application could trigger /then/ the installation of the recommended packages.
It doesn't need to be plugins, but that's one, yes.
Ok, then I think I got your idea right - but it still leads to the problem that the main program can't possibly know which extensible features have all ever been coded for this application. So the program itself can't possibly know what you need to install. I'd seen some packages hinting at what might be missing (there were even some patches to make it match the openSUSE package names in some cases) - but that's a very limited usecase and if I remember correctly, that was on an interpreted language (python), where it's more common that you miss some dependencies. Most 'upstreams' expect the program to be completely installed when built - the splitting off sub-packages is in most cases not what the software author would expect, but we do it do limit the space here and there. so having a software author add features that he never intended (and not directly works in favor of his application) makes it less probable that it would happen (for totem it was considered probable enough that you get a video file it can't play, that's why it was done in first place) Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-28 15:51, Dimstar / Dominique Leuenberger wrote:
On Tue, 2015-07-28 at 15:43 +0200, Carlos E. R. wrote:
Ok, then I think I got your idea right - but it still leads to the problem that the main program can't possibly know which extensible features have all ever been coded for this application. So the program itself can't possibly know what you need to install. I'd seen some packages hinting at what might be missing (there were even some patches to make it match the openSUSE package names in some cases) - but that's a very limited usecase and if I remember correctly, that was on an interpreted language (python), where it's more common that you miss some dependencies. Most 'upstreams' expect the program to be completely installed when built - the splitting off sub-packages is in most cases not what the software author would expect, but we do it do limit the space here and there.
Yes, that's it. As I said (or wanted to), it is a dream I have :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW3ifQACgkQja8UbcUWM1xt8gD8D6KDiSJsFuY/x7uG7T72Ecvg AjhN3qLnuRUp9/PvCvYA/3qEJ8Ao0cp61ydu0W/rx1TI86sjqeOqJRxbimFZGFOV =2w+Q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
I am not sure if it is bad practice to respond to old threads or if I should make new one and reference (didn't see in netiquette). For those that were interested in the priority option I finally got around to filing a pull request to add the option to set priority on addrepo command. Also allows overriding when adding via a .repo file. https://github.com/openSUSE/zypper/pull/81 If anyone here is relevant to review that would be great. Otherwise, I hope to follow this up with a few more priority related improvements since this seems to be one of the more important items from the wishlist. -- Jimmy On Tue, Jul 28, 2015 at 8:56 AM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-28 15:51, Dimstar / Dominique Leuenberger wrote:
On Tue, 2015-07-28 at 15:43 +0200, Carlos E. R. wrote:
Ok, then I think I got your idea right - but it still leads to the problem that the main program can't possibly know which extensible features have all ever been coded for this application. So the program itself can't possibly know what you need to install. I'd seen some packages hinting at what might be missing (there were even some patches to make it match the openSUSE package names in some cases) - but that's a very limited usecase and if I remember correctly, that was on an interpreted language (python), where it's more common that you miss some dependencies. Most 'upstreams' expect the program to be completely installed when built - the splitting off sub-packages is in most cases not what the software author would expect, but we do it do limit the space here and there.
Yes, that's it.
As I said (or wanted to), it is a dream I have :-)
- -- Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlW3ifQACgkQja8UbcUWM1xt8gD8D6KDiSJsFuY/x7uG7T72Ecvg AjhN3qLnuRUp9/PvCvYA/3qEJ8Ao0cp61ydu0W/rx1TI86sjqeOqJRxbimFZGFOV =2w+Q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2015-10-28 07:04, Jimmy Berry wrote:
I am not sure if it is bad practice to respond to old threads or if I should make new one and reference (didn't see in netiquette).
For me, it is fine :-) Some say a link is better.
For those that were interested in the priority option I finally got around to filing a pull request to add the option to set priority on addrepo command. Also allows overriding when adding via a .repo file.
Nice :-) There is a "zypp-devel" mail list, you could try writing there. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Am 28.07.2015 um 14:57 schrieb Dimstar / Dominique Leuenberger:
please read my follow-up mail in this thread, which explains what totem (the GNOME Video Player) already does in combination with PackageKit/GNOME-Software.
Have you tried that recently? I think even with 13.2 totem fails to play my anne_will.mp4 test culprit. It does notice that a codec is missing, but in the end nothing provides that codec. Until I open a shell and dup to packman, install gstreamer-ugly, or whatever it takes to get it going. Olaf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-07-28 at 15:11 +0200, Olaf Hering wrote:
Am 28.07.2015 um 14:57 schrieb Dimstar / Dominique Leuenberger:
please read my follow-up mail in this thread, which explains what totem (the GNOME Video Player) already does in combination with PackageKit/GNOME-Software.
Have you tried that recently? I think even with 13.2 totem fails to play my anne_will.mp4 test culprit. It does notice that a codec is missing, but in the end nothing provides that codec.
Until I open a shell and dup to packman, install gstreamer-ugly, or whatever it takes to get it going.
Actually, yes, just now - as I even created screenshots for the other mail. And I would never ever dup to PM.. if I want 'one gstreamer codec package', I'm not going to replace half my setup with packages from a random 3rd party repo (ok, this got much better with PM-Essentials - but a DUP is still way above what I'd accept). Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-28 15:15, Dimstar / Dominique Leuenberger wrote:
And I would never ever dup to PM.. if I want 'one gstreamer codec package', I'm not going to replace half my setup with packages from a random 3rd party repo (ok, this got much better with PM-Essentials - but a DUP is still way above what I'd accept).
Many people do it, as it is one of the published methods in many places. Notice that it never is a single package you need. You need all the gstreamer packages in PM, and some other things. There are so many needed packages for full multimedia, and so easy to miss some of them (with strange symptoms), that the recommendation is either a zypper dup from packman, or a switch system packages to this repo in yast. Yes, that switches also some other packages I do not want, which I then switch back. These are fewer, so it is easier this way. There is also a one click link somewhere that contains a long list of packages to install. And anyway, many/most/all? of the packages are in fact linked from OBS, or maintained by the same people as in OBS, so I basically have the same trust on PM as in oS :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW3hJcACgkQja8UbcUWM1ypxAD+P++GGUhSfu+zUCxqj7o8no7c h6HZESv1ewtRpzPA5CsBAIggZelz6G1zzd7XkrA5luxyMMy4wTfF/I/OOGUBWJSF =b3KT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.07.2015 um 15:33 schrieb Carlos E. R.:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-28 15:15, Dimstar / Dominique Leuenberger wrote: There is also a one click link somewhere that contains a long list of packages to install.
snip this one? http://opensuse-community.org/ In fact for 13.2 release I helped updating it. But it is too hard to find for new users. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-28 15:38, Thomas Langkamp wrote:
Am 28.07.2015 um 15:33 schrieb Carlos E. R.:
There is also a one click link somewhere that contains a long list of packages to install.
snip
this one? http://opensuse-community.org/
Yep :-)
In fact for 13.2 release I helped updating it. But it is too hard to find for new users.
A bit, yes. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW3h10ACgkQja8UbcUWM1zO+gD/aDcdX9T9RstJ734xQ3DCkhkl HeeDmdavrx8p+RhM4OoA/AyzmR/iZQ4JDfYwRt7/EBtxwYpCUibF9QSuEQVl+jk1 =4Y0W -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2015-07-28 at 15:33 +0200, Carlos E. R. wrote:
Many people do it, as it is one of the published methods in many places. Notice that it never is a single package you need. You need all the gstreamer packages in PM, and some other things. There are so many needed packages for full multimedia, and so easy to miss some of them (with strange symptoms), that the recommendation is either a zypper dup from packman, or a switch system packages to this repo in yast. Yes, that switches also some other packages I do not want, which I then switch back. These are fewer, so it is easier this way.
For GStreamer, this is only partially true.. the packaging is done in a way that all ADDED codecs (the patent problematic ones) are in an ADDON package (-addon-orig), intentionally for not having a need to replace base system packages. The same is true for the VLC package, where a vlc-codecs is produced, again, so that it can be EXTENDED instead of replaced. But as PM does not provide the persion of the base distribution for each repo, but the one linked from multimedia:libs, this is broken, ass there is likely a newer version there... and that's exactly why I do not use PackMan (but, yes, I am proficient enough in this stuff to manage my own setup). And as said: I do not use packman, yet can do all I need to do on my machine.. so claiming that you MUST have PM added is a bit over -enthusiastic.
And anyway, many/most/all? of the packages are in fact linked from OBS, or maintained by the same people as in OBS, so I basically have the same trust on PM as in oS :-)
most are linked to devel projects - which per definition are not forcibly ready for inclusion into the distribution... and often are in different versions to what was integrated. Often this is not a problem, sometimes they are not fully backwards compatible (as I don't run PM anymore for many years, I can't make a statement if this (still) happens or how often... but I certainly was bitten by that a couple years ago - which is why I stopped relying on this repo) Not to say you should not use it - if it works for you, by all means: do use it. Dominique -- Dimstar / Dominique Leuenberger <dimstar@opensuse.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-28 15:41, Dimstar / Dominique Leuenberger wrote:
And as said: I do not use packman, yet can do all I need to do on my machine.. so claiming that you MUST have PM added is a bit over -enthusiastic.
Absolutely :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW3h8wACgkQja8UbcUWM1ykPQEAl3w0fs96e0C8heEINydF+4h8 +dKJnUfiIjCVvBAfQsIA+wZ35l2PTC74udxctUrLilNhBIyYD08h7qFuSvRE+5/d =cxSH -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2015-07-28 10:34, Thomas Langkamp wrote:
The openSUSE Project works hard to only provide tested software of a high quality.
Why do some other distros (ubuntu) do not have those problems? Do they pay?
Maybe they do - the war budget of Mark/Canonical is said not to be small. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On Jul 23 10:46 Thomas Langkamp wrote (excerpt):
d) install recommends only once during installation as default, so that uninstalled apps do not come back => so far +1 for this
Hereby a -1 from me. Reason: When an unexperienced user installs an application later, he usually needs all what is recommended by this particular application. Installing recommends only during initial installation results "broken" (from unexperienced user point of view) installations of later applications. BUT: I wrote "what is recommended by this particular application". This means when foo is to be installed and foo recommends bar and bar recommends baz, then only foo bar and baz should get installed by default. In contrast when qux is already installed and qux recommends quux and the above foo is to be installed, then quux should not also get installed by default. In short: By default no recommends from already installed packages. By default only recommends from to be installed packages. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-23 11:29, Johannes Meixner wrote:
In short: By default no recommends from already installed packages. By default only recommends from to be installed packages.
Yes. The behaviour that pops out quite often in the openSUSE forums is that when people remove a package, it gets automatically reinstalled next time, because it is recommended by another package that is still installed. This started to happen with 13.2. Till 13.1, yast remembers that it was removed manually. I understand that this had to be disabled for some reason, but it is often cause of complains. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWw6OwACgkQja8UbcUWM1zQ9wD/S/fKj7q8iHevKSrH4iPJCaj6 BViGtCk8ug8dZkp5xXQA/06qz0NitrFFGwdkkxv9YLwKgTP2+Vbq8RH69JbRQ5I4 =04z0 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-23 10:46, Thomas Langkamp wrote:
The above is valid: TW in its current form is for experts / experienced users / users following this list. That is exactly why I started this discussion:
subject: "A users wishlist to make zypper up/dup & suse noob-friendly"
See? I said implicitly that zypper is too complicated and my wish is, that it - or another update mechanism - would make TW beginner-friendly.
Huh. Misunderstanding here. When I say that TW is for experts, or at least for experienced users, I'm not thinking only of zypper. I'm thinking of the overall TW concept. It is inherent to being on the edge of development. Changes appears constantly, and sometimes causing breakage (or partial breakage). Ok, must of it is catched by openQA, but other things are detected later, by humans. Even without breakage, changes in services and applications means that the administrators and users have to read docs and adapt their setups; and being the edge, it is these users who have to find out how to deal with these changes on their own: chances are they are the first to do it in the entire world. Thus I'm against easing much the installation of TW: it would be a false feeling. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWw6zwACgkQja8UbcUWM1w57AEAgZ/wkg5EKgwlkdf33Hor1qbg sGDgMR8ArzqxlQ/tGyQA/Rm2ZxXLKAFNcCNp0dAaDuyYeWDbyeDK5TTzf/Xpm7zd =Stw4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 07/23/2015 09:25 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-23 10:46, Thomas Langkamp wrote:
The above is valid: TW in its current form is for experts / experienced users / users following this list. That is exactly why I started this discussion:
subject: "A users wishlist to make zypper up/dup & suse noob-friendly"
See? I said implicitly that zypper is too complicated and my wish is, that it - or another update mechanism - would make TW beginner-friendly.
Huh. Misunderstanding here. When I say that TW is for experts, or at least for experienced users, I'm not thinking only of zypper. I'm thinking of the overall TW concept. It is inherent to being on the edge of development.
Changes appears constantly, and sometimes causing breakage (or partial breakage). Ok, must of it is catched by openQA, but other things are detected later, by humans. Even without breakage, changes in services and applications means that the administrators and users have to read docs and adapt their setups; and being the edge, it is these users who have to find out how to deal with these changes on their own: chances are they are the first to do it in the entire world.
Thus I'm against easing much the installation of TW: it would be a false feeling.
- -- Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlWw6zwACgkQja8UbcUWM1w57AEAgZ/wkg5EKgwlkdf33Hor1qbg sGDgMR8ArzqxlQ/tGyQA/Rm2ZxXLKAFNcCNp0dAaDuyYeWDbyeDK5TTzf/Xpm7zd =Stw4 -----END PGP SIGNATURE-----
+1 Cheers! Roman ICQ: 551368250 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 25.07.2015 um 00:36 schrieb Roman Bysh:
On 07/23/2015 09:25 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-23 10:46, Thomas Langkamp wrote:
The above is valid: TW in its current form is for experts / experienced users / users following this list. That is exactly why I started this discussion:
subject: "A users wishlist to make zypper up/dup & suse noob-friendly"
See? I said implicitly that zypper is too complicated and my wish is, that it - or another update mechanism - would make TW beginner-friendly.
Huh. Misunderstanding here. When I say that TW is for experts, or at least for experienced users, I'm not thinking only of zypper. I'm thinking of the overall TW concept. It is inherent to being on the edge of development.
Changes appears constantly, and sometimes causing breakage (or partial breakage). Ok, must of it is catched by openQA, but other things are detected later, by humans. Even without breakage, changes in services and applications means that the administrators and users have to read docs and adapt their setups; and being the edge, it is these users who have to find out how to deal with these changes on their own: chances are they are the first to do it in the entire world.
Thus I'm against easing much the installation of TW: it would be a false feeling.
- -- Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux)
iF4EAREIAAYFAlWw6zwACgkQja8UbcUWM1w57AEAgZ/wkg5EKgwlkdf33Hor1qbg sGDgMR8ArzqxlQ/tGyQA/Rm2ZxXLKAFNcCNp0dAaDuyYeWDbyeDK5TTzf/Xpm7zd =Stw4 -----END PGP SIGNATURE-----
+1
Cheers!
Roman
ICQ: 551368250
Sad to hear that :/ There seems to be no hope here, that making TW beginner-friendly is doable or desirable. However the remainder of my proposed changes also apply to Leap, 13.2 etc. as already said twice. however, thanks for the input, even if I do not agree with them. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-28 10:10, Thomas Langkamp wrote:
Sad to hear that :/ There seems to be no hope here, that making TW beginner-friendly is doable or desirable.
No; I'm sure there is desire and interest to make TW easy and beginners friendly. I simply think it is impossible (it is inherent on its very nature or definition), and others agree. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlW3fUwACgkQja8UbcUWM1z2twD+MfFWVpZrZbDCwcF1OAP537JR YxCMfwv8ZD9ZD6IyzZABAIH4dKMFU64CN9POStznq7JtFenfWPBV5aygdWHAQ0tE =+Rpn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 28.07.2015 um 15:02 schrieb Carlos E. R.:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-28 10:10, Thomas Langkamp wrote:
Sad to hear that :/ There seems to be no hope here, that making TW beginner-friendly is doable or desirable.
No; I'm sure there is desire and interest to make TW easy and beginners friendly. I simply think it is impossible (it is inherent on its very nature or definition), and others agree.
so you desire the impossible? That makes no sense to me. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (10)
-
Carlos E. R. -
Carlos E. R. -
Dimstar / Dominique Leuenberger -
Jan Engelhardt -
Jimmy Berry -
Johannes Meixner -
Olaf Hering -
Richard Brown -
Roman Bysh -
Thomas Langkamp