[opensuse-factory] Some packages not being removed, despite notifications in Zypper.
Hello mailing list! I have the following mystery I would like to understand. When I run zypper dup this is the output I get: " The following 5 applications are going to be REMOVED: ImagePlugin-Color ImagePlugin-Decorate ImagePlugin-Enhance ImagePlugin- FxFilters ImagePlugin-Transform No additional space will be used or freed after the operation. Nothing to do. " I don't see any of these packages in the repositories, though a quick online search tells me they are digikam related. Anyone here who could inform me as to what may be going on?
On Thu, 2016-01-28 at 19:05 -0600, Chan Ju Ping wrote:
Hello mailing list!
I have the following mystery I would like to understand. When I run zypper dup this is the output I get:
" The following 5 applications are going to be REMOVED:
ImagePlugin-Color ImagePlugin-Decorate ImagePlugin-Enhance ImagePlugin- FxFilters ImagePlugin-Transform
No additional space will be used or freed after the operation. Nothing to do. "
I don't see any of these packages in the repositories, though a quick online search tells me they are digikam related. Anyone here who could inform me as to what may be going on?
It says 'applictions' - not packages... there is a subtle difference. In this case, the issue is that the meta data generated for the packages is not fully correct. With the info at hand, zypper knows 'I have this now installed, but per the info I receive, the new 'package' no longer has the 'reference to the application'. In fact, it's about 'plugins' here. Using zypper, you can search for apps for example using: zypper se -t application This is getting more an more interesting as 'users are interested in applications, not packages' - packages are a technicality. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jan 29, 2016 at 11:50:46AM +0100, Dominique Leuenberger / DimStar wrote:
On Thu, 2016-01-28 at 19:05 -0600, Chan Ju Ping wrote:
I have the following mystery I would like to understand. When I run zypper dup this is the output I get:
" The following 5 applications are going to be REMOVED:
ImagePlugin-Color ImagePlugin-Decorate ImagePlugin-Enhance ImagePlugin- FxFilters ImagePlugin-Transform
No additional space will be used or freed after the operation. Nothing to do. "
I don't see any of these packages in the repositories, though a quick online search tells me they are digikam related. Anyone here who could inform me as to what may be going on?
It says 'applictions' - not packages... there is a subtle difference. In this case, the issue is that the meta data generated for the packages is not fully correct. With the info at hand, zypper knows 'I have this now installed, but per the info I receive, the new 'package' no longer has the 'reference to the application'. In fact, it's about 'plugins' here.
Using zypper, you can search for apps for example using: zypper se -t application
This is getting more an more interesting as 'users are interested in applications, not packages' - packages are a technicality.
Honestly I don't need it and several others too. Instead we're forced to download this meta data again and again and in particular when you're on the road this is more than annoying. Seife made a suggestion but the patch wasn't good enought. Instead to enhance it we're currently in the situation to get a quite missleading message presented while updating Tumbleweed. Please merge Seifes patch or help him to enhance it. Or drop this stuff which only is of use to Gnome users IIRC. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Fri, Jan 29, 2016 at 3:31 PM, Lars Müller <lmuelle@suse.com> wrote:
This is getting more an more interesting as 'users are interested in applications, not packages' - packages are a technicality.
Honestly I don't need it and several others too.
You hardly qualify as "user" :p Sorry, could not resist. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2016-01-29 at 13:31 +0100, Lars Müller wrote:
On Fri, Jan Please merge Seifes patch or help him to enhance it. Or drop this stuff which only is of use to Gnome users IIRC.
No. Help KDE Upstream to get their app center finally in a shape as well and stop arguing that this is a GNOME thing. Appstream is intentionally NOT DE-specific Sorry, this is mumbo jumbo non-sense. The fact that zypper is 'just learning how to interpret the complex data' is a different story - and this needs fixing / training (maybe wise for now to tell zypp not to show such messages except if you're a user that understands what he's doing and that understand appstream - so that the ones actually caring for it can fix it without confusing the others) Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jan 29, 2016 at 01:36:27PM +0100, Dominique Leuenberger / DimStar wrote:
On Fri, 2016-01-29 at 13:31 +0100, Lars Müller wrote:
On Fri, Jan Please merge Seifes patch or help him to enhance it. Or drop this stuff which only is of use to Gnome users IIRC.
No. Help KDE Upstream to get their app center finally in a shape as well and stop arguing that this is a GNOME thing. Appstream is intentionally NOT DE-specific
Sorry, this is mumbo jumbo non-sense. The fact that zypper is 'just learning how to interpret the complex data' is a different story - and this needs fixing / training (maybe wise for now to tell zypp not to show such messages except if you're a user that understands what he's doing and that understand appstream - so that the ones actually caring for it can fix it without confusing the others)
Ok, if this is non-sense, then it's time to stop using Tumbleweed? You're not helping to get this issue out of the way. Instead you blame the messanger. Nice. This noice is there and if it is independent of the DE than it's even worse and what's causing it should be removed. Thanks, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Fri, 2016-01-29 at 13:50 +0100, Lars Müller wrote:
Ok, if this is non-sense, then it's time to stop using Tumbleweed?
???
You're not helping to get this issue out of the way. Instead you blame the messanger. Nice.
??? I don't blame zypper as messenger.. all I said is that it's still learning some of the feature set - AND most such messages can even be broken down to a packaging error (not in case of digikam though)
This noice is there and if it is independent of the DE than it's even worse and what's causing it should be removed.
RIGHT! Zypper is DE-agnostic. I would say if zypper behaves different based on the DE used, it would be broken. It's a CLI tool afeer all! NO DE is at fault here. digikam is a KDE app right? One can argue that Upstream CARES for this kind of meta info for Software Centers: or they would not ship the files. I still stand: let's FIX things, not reduce features. Cheers, Dominique (please keep the thread short so it does not bypass the size af AppStream metadata that I already have to download) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2016-01-29 13:56, Dominique Leuenberger / DimStar wrote:
I still stand: let's FIX things, not reduce features.
"Perfection is Achieved Not When There Is Nothing More to Add, But When There Is Nothing Left to Take Away" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.01.2016 um 13:56 schrieb Dominique Leuenberger / DimStar:
On Fri, 2016-01-29 at 13:50 +0100, Lars Müller wrote:
Ok, if this is non-sense, then it's time to stop using Tumbleweed?
???
Well, Factory/Tumbleweed updates are painful because of having to download the metadata all the time.
??? I don't blame zypper as messenger.. all I said is that it's still learning some of the feature set - AND most such messages can even be broken down to a packaging error (not in case of digikam though)
And it would be very nice if libzypp could learn how to skip this completely. /etc/zypp/zypp.conf metadata.appstream.download = {never,on-demand,always} I would not even start to argue if the default would not be "never", but "on-demand" :-P
This noice is there and if it is independent of the DE than it's even worse and what's causing it should be removed.
RIGHT! Zypper is DE-agnostic. I would say if zypper behaves different based on the DE used, it would be broken. It's a CLI tool afeer all! NO DE is at fault here. digikam is a KDE app right? One can argue that Upstream CARES for this kind of meta info for Software Centers: or they would not ship the files.
I still stand: let's FIX things, not reduce features.
I still stand: don't waste everyone's time and bandwidth for marginal benefits of a few users.
(please keep the thread short so it does not bypass the size af AppStream metadata that I already have to download)
You don't, just use my patched libzypp from home:seife:testing! :-) And to exceed the size of these metadata, we would need to write waaaay more mails :-) Have fun, seife -- 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
Am 29.01.2016 um 16:18 schrieb Stefan Seyfried:
Am 29.01.2016 um 13:56 schrieb Dominique Leuenberger / DimStar:
Well, Factory/Tumbleweed updates are painful because of having to download the metadata all the time.
??? I don't blame zypper as messenger.. all I said is that it's still learning some of the feature set - AND most such messages can even be broken down to a packaging error (not in case of digikam though)
And it would be very nice if libzypp could learn how to skip this completely.
...skip this download...
/etc/zypp/zypp.conf
metadata.appstream.download = {never,on-demand,always}
By the way -- a (not so) fun fact: the metadata is published and downloaded multiple times. * http://download.opensuse.org/factory/repo/oss * http://download.opensuse.org/factory/repo/debug * http://download.opensuse.org/factory/repo/src-oss All contain similar sized appdata-* files. -- 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 Fri, 2016-01-29 at 16:34 +0100, Stefan Seyfried wrote:
By the way -- a (not so) fun fact: the metadata is published and downloaded multiple times.
* http://download.opensuse.org/factory/repo/oss * http://download.opensuse.org/factory/repo/debug * http://download.opensuse.org/factory/repo/src-oss
All contain similar sized appdata-* files.
repo-oss: appdata.xml.gz 27-Jan-2016 03:15 1.6M repo-debug: appdata.xml.gz 27-Jan-2016 03:27 94 repo-src-oss: appdata.xml.gz 27-Jan-2016 03:31 94 'almost the same size' - the two times 94bytes are exactly the same size (and same content) But I *do* see an error there: there is actually no reason why the appdata-icons would have content in src/debug repo... *THAT* is called a bug. I'll have a look at that one (somebody feel free to file one if you want to monitor on it) Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.01.2016 um 16:52 schrieb Dominique Leuenberger / DimStar:
On Fri, 2016-01-29 at 16:34 +0100, Stefan Seyfried wrote:
By the way -- a (not so) fun fact: the metadata is published and downloaded multiple times.
* http://download.opensuse.org/factory/repo/oss * http://download.opensuse.org/factory/repo/debug * http://download.opensuse.org/factory/repo/src-oss
All contain similar sized appdata-* files.
repo-oss: appdata.xml.gz 27-Jan-2016 03:15 1.6M
repo-debug: appdata.xml.gz 27-Jan-2016 03:27 94
repo-src-oss: appdata.xml.gz 27-Jan-2016 03:31 94
'almost the same size' - the two times 94bytes are exactly the same size (and same content)
I looked at the icons, which are the biggest (and -- in case of zypper -- absolutely useless ;-)) part. And the icons were the part which initially made me notice this slow-updates-down-to-a-crawl "feature" :-) -- 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 Fri, 2016-01-29 at 17:10 +0100, Stefan Seyfried wrote:
Am 29.01.2016 um 16:52 schrieb Dominique Leuenberger / DimStar:
On Fri, 2016-01-29 at 16:34 +0100, Stefan Seyfried wrote:
By the way -- a (not so) fun fact: the metadata is published and downloaded multiple times.
* http://download.opensuse.org/factory/repo/oss * http://download.opensuse.org/factory/repo/debug * http://download.opensuse.org/factory/repo/src-oss
All contain similar sized appdata-* files.
repo-oss: appdata.xml.gz 27-Jan-2016 03:15 1.6M
repo-debug: appdata.xml.gz 27-Jan-2016 03:27 94
repo-src-oss: appdata.xml.gz 27-Jan-2016 03:31 94
'almost the same size' - the two times 94bytes are exactly the same size (and same content)
I looked at the icons, which are the biggest (and -- in case of zypper -- absolutely useless ;-)) part.
And the icons were the part which initially made me notice this slow-updates-down-to-a-crawl "feature" :-)
Actually I already managed to spot where things go wrong, fixed it, submitted it and some of the future TW snaoshots will publish the icon tarball only once, in the repo where the apps actually live... so /debug and /src repos will both save quite some bandwidth here Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Freitag, 29. Januar 2016 17:12:48 CET Dominique Leuenberger / DimStar wrote:
On Fri, 2016-01-29 at 17:10 +0100, Stefan Seyfried wrote:
Actually I already managed to spot where things go wrong, fixed it, submitted it and some of the future TW snaoshots will publish the icon tarball only once, in the repo where the apps actually live... so /debug and /src repos will both save quite some bandwidth here
Cheers, Dominique
Thanks Dominique for fixing this bug. Althoug I understand some tumbleweed (or any other (open)SUSE) variant) users are perfectly happy with the current package information and software install process, it would be nice if these persons would try to adapt their view to one of a new openSUSE/Linux user. A modern software manager has to compete with todays smartphone "App stores" - screenshots, no-techno-babble description. If there are technical problems, solve them. The icons should be almost static data, so downloads should be rare. If small changes cause whole metadata download, change the metadata format, make containers/archives rsyncable. Huge downloads are bad, but this can be solved on a technical level. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.01.2016 um 18:38 schrieb Stefan Bruens:
Althoug I understand some tumbleweed (or any other (open)SUSE) variant) users are perfectly happy with the current package information and software install process, it would be nice if these persons would try to adapt their view to one of a new openSUSE/Linux user.
It's unlikely I'll change my opinion about the usefulness of this appstream stuff *for me*.
A modern software manager has to compete with todays smartphone "App stores" - screenshots, no-techno-babble description.
I partly agree with that, and I have stated that before. But not by forcing everyone to carry the burden with every update.
If there are technical problems, solve them.
Exactly. Download "the crap" ;) on demand, when you have a system that will actually use them.
The icons should be almost static data, so downloads should be rare.
Should. Fact is, the tarball is obviously rebuilt on every publish of the repo.
If small changes cause whole metadata download, change the metadata format, make containers/archives rsyncable. Huge downloads are bad, but this can be solved on a technical level.
No matter how big or small: just not downloading them at all if they are not needed saves both bandwidth (on both sides) and storage (on my side). (I do not agree that smartphone-like appstores are the best solution -- e.g. it is often impossible to even find out a version number of the stuff you are installing.) -- 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
* Dominique Leuenberger / DimStar <dimstar@opensuse.org> [01-29-16 11:14]:
On Fri, 2016-01-29 at 17:10 +0100, Stefan Seyfried wrote:
Am 29.01.2016 um 16:52 schrieb Dominique Leuenberger / DimStar:
On Fri, 2016-01-29 at 16:34 +0100, Stefan Seyfried wrote:
By the way -- a (not so) fun fact: the metadata is published and downloaded multiple times.
* http://download.opensuse.org/factory/repo/oss * http://download.opensuse.org/factory/repo/debug * http://download.opensuse.org/factory/repo/src-oss
All contain similar sized appdata-* files.
repo-oss: appdata.xml.gz 27-Jan-2016 03:15 1.6M
repo-debug: appdata.xml.gz 27-Jan-2016 03:27 94
repo-src-oss: appdata.xml.gz 27-Jan-2016 03:31 94
'almost the same size' - the two times 94bytes are exactly the same size (and same content)
I looked at the icons, which are the biggest (and -- in case of zypper -- absolutely useless ;-)) part.
And the icons were the part which initially made me notice this slow-updates-down-to-a-crawl "feature" :-)
Actually I already managed to spot where things go wrong, fixed it, submitted it and some of the future TW snaoshots will publish the icon tarball only once, in the repo where the apps actually live... so /debug and /src repos will both save quite some bandwidth here
here are two that didn't get fixed: calibre-ebook-viewer calibre-gui tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2016-01-29 at 19:34 -0500, Patrick Shanahan wrote:
* Dominique Leuenberger / DimStar <dimstar@opensuse.org> [01-29-16 11:14]:
On Fri, 2016-01-29 at 17:10 +0100, Stefan Seyfried wrote:
Am 29.01.2016 um 16:52 schrieb Dominique Leuenberger / DimStar:
On Fri, 2016-01-29 at 16:34 +0100, Stefan Seyfried wrote:
By the way -- a (not so) fun fact: the metadata is published and downloaded multiple times.
* http://download.opensuse.org/factory/repo/oss * http://download.opensuse.org/factory/repo/debug * http://download.opensuse.org/factory/repo/src-oss
All contain similar sized appdata-* files.
repo-oss: appdata.xml.gz 27-Jan-2016 03:15 1.6M
repo-debug: appdata.xml.gz 27-Jan-2016 03:27 94
repo-src-oss: appdata.xml.gz 27-Jan-2016 03:31 94
'almost the same size' - the two times 94bytes are exactly the same size (and same content)
I looked at the icons, which are the biggest (and -- in case of zypper -- absolutely useless ;-)) part.
And the icons were the part which initially made me notice this slow-updates-down-to-a-crawl "feature" :-)
Actually I already managed to spot where things go wrong, fixed it, submitted it and some of the future TW snaoshots will publish the icon tarball only once, in the repo where the apps actually live... so /debug and /src repos will both save quite some bandwidth here
here are two that didn't get fixed: calibre-ebook-viewer calibre-gui
Not surprising - I referred to having fixed the multiple publishing of the icons tarball in multiple repositories, where it should only be in the main repo. Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 29 Jan 2016 13:36, Dominique Leuenberger / DimStar wrote:
On Fri, 2016-01-29 at 13:31 +0100, Lars Müller wrote:
On Fri, Jan
Please merge Seifes patch or help him to enhance it. Or drop this stuff which only is of use to Gnome users IIRC.
No. Help KDE Upstream to get their app center finally in a shape as well and stop arguing that this is a GNOME thing. Appstream is intentionally NOT DE-specific
Sorry, this is mumbo jumbo non-sense. The fact that zypper is 'just learning how to interpret the complex data' is a different story - and this needs fixing / training (maybe wise for now to tell zypp not to show such messages except if you're a user that understands what he's doing and that understand appstream - so that the ones actually caring for it can fix it without confusing the others)
IMHO, it a matter of wrong defaults. The cli tool 'zypper' should NOT show such messages unless an option is explicitly set to show this data. The cli tool is either used by experts, which are able to read "zypper help" or "man zypper" - or - and this is even more dangerous in the way of missinterpration: a casual user, that has no real experiance and/or training in administration of a system. So, in the interest of KISS, keep that data hidden until explicitly asked for. That libzypp provides this data is well and good. Just not in default for the cli. Idea: use a option: "showApplicationData" type "boolean", default "no" in the /etc/zypp/zypper.conf file. That way all will be happy, and served well. Have a nice weekend - Yamaban.
On Fri, 2016-01-29 at 13:55 +0100, Yamaban wrote:
On Fri, 29 Jan 2016 13:36, Dominique Leuenberger / DimStar wrote:
On Fri, 2016-01-29 at 13:31 +0100, Lars Müller wrote:
On Fri, Jan
Please merge Seifes patch or help him to enhance it. Or drop this stuff which only is of use to Gnome users IIRC.
No. Help KDE Upstream to get their app center finally in a shape as well and stop arguing that this is a GNOME thing. Appstream is intentionally NOT DE-specific
Sorry, this is mumbo jumbo non-sense. The fact that zypper is 'just learning how to interpret the complex data' is a different story - and this needs fixing / training (maybe wise for now to tell zypp not to show such messages except if you're a user that understands what he's doing and that understand appstream - so that the ones actually caring for it can fix it without confusing the others)
IMHO, it a matter of wrong defaults. The cli tool 'zypper' should NOT show such messages unless an option is explicitly set to show this data.
The cli tool is either used by experts, which are able to read "zypper help" or "man zypper" - or - and this is even more dangerous in the way of missinterpration: a casual user, that has no real experiance and/or training in administration of a system.
So, in the interest of KISS, keep that data hidden until explicitly asked for.
That libzypp provides this data is well and good. Just not in default for the cli.
Idea: use a option: "showApplicationData" type "boolean", default "no" in the /etc/zypp/zypper.conf file.
That way all will be happy, and served well.
Have a nice weekend - Yamaban.
That goes pretty much in line with the idea I formulated, you just did a much better job in thinking implementation wise, I only formulated feature wise. We should ensure though that sufficient people switch it on and report on issues - or zypper / libzypp / libsolv won't ever have the chance to fix all the issues (and yes: the bugs reported ARE being worked on) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Yamaban, Am 29.01.2016 um 13:55 schrieb Yamaban:
So, in the interest of KISS, keep that data hidden until explicitly asked for.
Unfortunately, this only solves the cosmetic part of the issue. I personally could not care less about that. The metadata is quite big and apparently served always from the main mirror, which is often overloaded. This is what I'm trying to avoid.
That libzypp provides this data is well and good. Just not in default for the cli.
It does not need to gather / download this data at all if there is no user for 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
That libzypp provides this data is well and good. Just not in default for the cli.
It does not need to gather / download this data at all if there is no user for it.
zypper IS a user of it: zypper in -t application JuK zypper in -t application "moserial Terminal" zypper se -t application Just because one does not know about the feature does not make the feature go away. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 29.01.2016 um 16:30 schrieb Dominique Leuenberger / DimStar:
It does not need to gather / download this data at all if there is no user for it.
zypper IS a user of it:
But it can work well without it. As my patch (which I am using for over 3 months now) clearly shows.
Just because one does not know about the feature does not make the feature go away.
Just because a feature is available does not make it useful for me. Just make the download of the metadata configurable, and everything else will follow almost automatically (I only very seldom see these "application foo will be uninstalled" messages from zypper, now that I do not download the metadata anymore). -- 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
Am 29.01.2016 um 13:36 schrieb Dominique Leuenberger / DimStar:
On Fri, 2016-01-29 at 13:31 +0100, Lars Müller wrote:
On Fri, Jan Please merge Seifes patch or help him to enhance it. Or drop this stuff which only is of use to Gnome users IIRC.
No. Help KDE Upstream to get their app center finally in a shape as well and stop arguing that this is a GNOME thing. Appstream is intentionally NOT DE-specific
Thanks, but I'm also not interested in a KDE solution. The whole concept of "APPS" instead of packages does not make sense *for me* (and I have a slight guess that Lars also does not really see the benefit he gets from it ;-). I understand and acknowledge that there are users who might have a different view on this, but I do not understand and approve that all other users have to suffer badly from this.
Sorry, this is mumbo jumbo non-sense. The fact that zypper is 'just learning how to interpret the complex data' is a different story - and this needs fixing / training (maybe wise for now to tell zypp not to show such messages except if you're a user that understands what he's doing and that understand appstream - so that the ones actually caring for it can fix it without confusing the others)
It still forces me to download huge, useless (for me) metadata. And because it is metadata, it is (AFAICT) always downloaded from the slow main mirror, making this a pain even with an 100mbit downstream pipe. The whole reason I even found out about this appstream stuff is that I was wondering why minimal daily Factory updates took so long. Guess what, it was *not* the few packages that got updated. The right thing (IMO) would be that a "appcenter" that wants to have the appstream metadata either downloads it by itself or, probably better, libzypp gets an interface for the "client" to request this metadata. And plain zypper will certainly not request this by default, since obviously it cannot handle it anyway. -- 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
Hi Lars, Am 29.01.2016 um 13:31 schrieb Lars Müller:
Seife made a suggestion but the patch wasn't good enought.
Just to make this clear: the patch *really* is not sufficient, I can understand why libzypp maintainers do not want to take it as-is. It was just the 5-minutes-quick-hack I could come up with easily. OTOH, I'm not planning to dig deeper into libzypp development, and since the patch is so simle, it has (until today) applied without problems to newer libzypp versions, so having this patch maintained by myself is easier than getting it properly fixed and implemented upstream.
Please merge Seifes patch or help him to enhance it.
"...or take it and fix it so that it can be merged." There is no way to help me enhance it :-P Best regards, -- 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 Friday, January 29, 2016 11:50:46 AM CST Dominique Leuenberger / DimStar wrote:
It says 'applictions' - not packages... there is a subtle difference. In this case, the issue is that the meta data generated for the packages is not fully correct. With the info at hand, zypper knows 'I have this now installed, but per the info I receive, the new 'package' no longer has the 'reference to the application'. In fact, it's about 'plugins' here.
Using zypper, you can search for apps for example using: zypper se -t application
This is getting more an more interesting as 'users are interested in applications, not packages' - packages are a technicality.
Cheers, Dominique
Thanks Dominique. What would be the recommended action in with this output? Follow Zypper's advise and try to remove it manually, or wait for future snapshots to hopefully cover the issue? -Ju Ping.
On Fri, 2016-01-29 at 10:19 -0600, Chan Ju Ping wrote:
This is getting more an more interesting as 'users are interested in applications, not packages' - packages are a technicality.
Cheers, Dominique
Thanks Dominique.
What would be the recommended action in with this output? Follow Zypper's advise and try to remove it manually, or wait for future snapshots to hopefully cover the issue?
Zypper is not really trying to remove them from the system. For now, ignore it until zypp gets around of handling this case properly. This specific case is tracked in https://bugzilla.opensuse.org/show_bug .cgi?id=961738 Cheers, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday, 29 January 2016 11:50:46 CST Dominique Leuenberger / DimStar wrote:
On Thu, 2016-01-28 at 19:05 -0600, Chan Ju Ping wrote:
Hello mailing list!
I have the following mystery I would like to understand. When I run zypper dup this is the output I get:
" The following 5 applications are going to be REMOVED:
ImagePlugin-Color ImagePlugin-Decorate ImagePlugin-Enhance ImagePlugin- FxFilters ImagePlugin-Transform
No additional space will be used or freed after the operation. Nothing to do. "
I don't see any of these packages in the repositories, though a quick online search tells me they are digikam related. Anyone here who could inform me as to what may be going on?
It says 'applictions' - not packages... there is a subtle difference. In this case, the issue is that the meta data generated for the packages is not fully correct. With the info at hand, zypper knows 'I have this now installed, but per the info I receive, the new 'package' no longer has the 'reference to the application'. In fact, it's about 'plugins' here.
Using zypper, you can search for apps for example using: zypper se -t application
This is getting more an more interesting as 'users are interested in applications, not packages' - packages are a technicality.
Cheers, Dominique
Latest zypper dup seems to have fixed the problem on the computer I am writing this email from. Interestingly enough, I am sitting beside another laptop I just converted to a Tumbleweed machine mere hours ago showing the same message. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (9)
-
Andrei Borzenkov -
Chan Ju Ping -
Dominique Leuenberger / DimStar -
Jan Engelhardt -
Lars Müller -
Patrick Shanahan -
Stefan Bruens -
Stefan Seyfried -
Yamaban