= Proposal topic = Due to intentional incompatibility PK now is trying to push its own depsolver. It not only does not use the same criteria to resolve multiple providers but it won't depsolve the same ways yum (and therefore anaconda) will.
This will create dependency and compatibility problems and worse yet,confusion for our users.
We've encountered this problem in the past with apt-rpm and smart. However, the number of users of either of those were so trivial as to not create many bug reports.
PK intends zif to be included, by default, with fedora in the future and if not explitcly included it will no doubt trickle in due to a dependency.
It would be best if yum-incompatible depsolvers be removed from the default set of pkgs (either explicitly or by dep).
From a QA and troubleshooting standpoint having multiple depsolvers is unacceptable. Just like with having multiple different kernel pkgs, it will create a set of options which are almost impossible to debug. Especially as, to the user, it will be difficult to determine which depsolver was being used - only that their system broke in hard-to-diagnose ways.
The yum team has dealt with exactly this situation in the past with people using rpm (--force --nodeps) and smart and then wondering why things were not working properly later. We've implemented a lot of code to determine when something has changed using a non-yum depsolver so we can more easily diagnose these cases. However, while we can determine when this occurs we cannot easily solve the problem that occurs - only know the root cause - which is the alternative depsolver.
Adding meeting keyword.
I would extend this from "depsolvers" to package management in general, because though it's one of the most visible parts depsolving differences are far from the only problem with swapping out core infrastructure like our package management. It was kind of "cute" that we allowed apt+smart+rpmreaper+whatever 10 years ago, while only allowing one kernel/libc/etc. but it's well past time when changing was viable without a huge desire across many components of the distro.
Replying to [ticket:669 skvidal]:
Says who? Elad created the feature page on his own. I didn't write the page, and I was only made aware of it when I was asked to check for corrections. ZIF stands for "Zero Insertion Force" which means I'm not going to push it myself. If people want to use it, then that's cool, but I'm not the one pushing it to be used by default.
Best for yum, and best for you. Really, a package manager is nothing special. It doesn't define the distribution and does not need special protection measures like no other framework.
Different tools for different things; Yum works best with servers and on the console, and Zif works best as a library in something GUI and high level.
Just like with having multiple different kernel pkgs...
And multiple desktops. And multiple mail servers. And multiple GUI toolkits.
....using rpm (--force --nodeps) and smart and then wondering why things were not working properly later.
Zif doesn't turn off the rpm dep checks, never has, and never will. I assume if zif is chosen to be exiled by fesco, then that is also curtains for smart. Which seems odd for a distro like Fedora.
Richard.
Replying to [comment:3 rhughes]:
Best for yum, and best for you.
I elected to not join the packaging team. I work for the fedora team. I'm not concerned for yum in this case. James is. I think that zif will cause considerable pain for fedora - which is my primary concern.
Zif doesn't turn off the rpm dep checks, never has, and never will. I assume if zif > is chosen to be exiled by fesco, then that is also curtains for smart.
Smart at least was not being pulled in by default to the distro and onto everyone's machines. Confusing our users and creating bugs. However, those who did choose to install smart did, in fact, run into depsolving problems and conflicts. They were a real joy to debug.
This is why zif, smart and apt shouldn't be around.
The package management system is the core of how we do everything in the fedora distribution. Depsolving is critical to how it all works. Consistency needs to be respected in the package mgmt system specifically so we can allow for diversity and pluralism in every other area of fedora.
Replying to [ticket:669 skvidal]: Just like with having multiple different kernel pkgs... And multiple desktops. And multiple mail servers. And multiple GUI toolkits.
These things are not like the given examples.
You can realistically have two users of a Fedora machine using two different editors, or GUIs. While they can't be (easily) run at the same time HTTP/SMTP/etc. servers have historically got a dispensation, even though it makes all of the packages that depend on them more painful, due to a perceived significant user demand to have not just postfix+apache-httpd and also that they are both "addon" packages.
However Fedora has repeatedly chosen not to allow users to pick their own core components, like the kernel. It's far past time to bring package management inline.
Replying to [comment:5 james]:
It's far past time to bring package management inline.
By that, I guess you mean "we have to remove anything doing package management that isn't yum"
Newsflash at 10: Yum doesn't work very well in multithreaded interactive programs written in C. For example, you can't "fix" yum to allow multiple locks so you can still read the rpmdb while you're downloading packages. Not allowing that makes we're sitting in a GUI program staring at a little spinner saying "Waiting for package manager lock". The designers hate it, the users don't understand it and it doesn't even work for me half the time. People also don't understand why we have to download all 300 Mb of packages before we can start installing updates and I don't understand this as a limitation either if each subtransaction is depsolvable. Basically yum isn't designed for this use case, and that's perfectly fine; yum works really well on the command line for administrators and wasn't designed to be low-latency and multithreaded.
My real issue here, is that the yum backend in PackageKit is unmaintained. I'm the only one that keeps things limping on and twice now I've been screwed when the yum API has changed without anyone telling me. Once just caused a regression, and once it caused a security CVE. I can't read the yum developer API docs, because there aren't any. To learn about yum I have to read the source code, and try to work out what's going on. When yum starts interacting with RHN, things get very "magic" indeed, and I'm pretty sure nobody understands really what is going on.
Unless the yum maintainers actually maintain the yum interface code in PackageKit (I've asked for help both publicly, and internally at Red Hat) and start to add features that I need for the desktop use case I don't see why I shouldn't develop something that does address the different use-cases we have for the desktop.
After all, if PackageKit sucks, it's me that looks bad.
= Proposal topic = Due to intentional incompatibility PK now is trying to push its own depsolver. It not only does not use the same criteria to resolve multiple providers but it won't depsolve the same ways yum (and therefore anaconda) will. It's not PK, it's not Richard, it's just me. And it's not due to an "intentional incompatibility". The only reason I want zif to be default backend for PK is that it's faster, and it doesn't block the UI while preforming operations.
It's not PK, it's not Richard, it's just me. And it's not due to an "intentional incompatibility". The only reason I want zif to be default backend for PK is that it's faster, and it doesn't block the UI while preforming operations.
AFAIK it does use exactly the same criteria. According to zif homepage, "Fast depsolving, using the '''same algorithms as yum'''".
This will create dependency and compatibility problems and worse yet,confusion for our users. Why? We've encountered this problem in the past with apt-rpm and smart. However, the number of users of either of those were so trivial as to not create many bug reports. PK intends zif to be included, by default, with fedora in the future and if not explitcly included it will no doubt trickle in due to a dependency. Again, not PK, only me.
Why? We've encountered this problem in the past with apt-rpm and smart. However, the number of users of either of those were so trivial as to not create many bug reports.
Again, not PK, only me.
"trickle in due to a dependency" - this is just plain ridiculous. Why would I want to do that? if FESCO doesn't want zif by default (eg. by not approving the feature page), I wouldn't dream of making it default ignoring FESCO's decision.
Due to intentional incompatibility
Zif is not being incompatible at all. It's trying hard to be compatible, and the yum developers are the ones who forced zif to turn off some of its compatibility features (yumdb access, yum.conf parsing).
The real reasons for zif are all spelled out on [http://people.freedesktop.org/~hughsient/zif/]. Yum is just not suitable for !PackageKit's needs.
This will create dependency and compatibility problems and worse yet,confusion for our users. We've encountered this problem in the past with apt-rpm and smart.
Nonsense, apt-rpm worked just fine until the big RPM API cleanup broke it. I haven't tried it lately because I'm now using KPackageKit, which doesn't have an apt-rpm backend, but AFAIK apt-rpm is working fine again.
Those depsolvers are not yum-incompatible, they can coexist just fine with yum.
You can realistically have two users of a Fedora machine using two different editors, or GUIs.
You can also realistically use 2 different depsolvers at the same time on the same machine, e.g. yum or apt-rpm for command-line operation and zif for !PackageKit. It will just work, as long as the RPM layer is shared.
And as I wrote on the mailing list:
If we were to keep only one depsolver, once zif is stable, which one would we want to keep: * the tool written in a slow interpreted language, which cannot even be loaded into the process of the backend for our default package management GUI, requiring complex hacks to be spawned out of process and to bridge the language gap, or * the tool written in the same compiled language as our default package management GUI (and its backend daemon) and by the same primary developer, which can be loaded simply as a shared library?
I know you want your own code to be used, but let's be honest…
Yum's reliance on Python is a major design flaw causing several problems for Fedora: * depsolving slowness and memory use (e.g. I'm sure Python is to blame for a significant part of Anaconda's skyrocketing memory requirements; !PackageKit update checks through yum are also a huge CPU and memory hog etc.), * making Python (a huge interpreter) part of the critical path, * upgrade issues like the infamous "yum from F10 updates has a higher EVR than yum from F11 GA, but is built against the old Python and won't run on F11" issue which was a PITA to recover from, * inability to be loaded as a shared library into compiled programs like the !PackageKit daemon, * relying on the deprecated Python 2 and slowing down Python 3 adoption.
(And to be honest, the attitude of the yum developers personally makes me want to switch to !PackageKit-zif (and back to apt-rpm for those cases where I need a command line) ASAP.)
I fully support Elad's [https://fedoraproject.org/wiki/Features/ZifByDefaultForDesktop] proposal. That said, I would personally like [https://bugzilla.redhat.com/show_bug.cgi?id=739282] and probably [https://bugzilla.redhat.com/show_bug.cgi?id=739283] addressed before zif becoming the default.
If the feature proposal is approved, Zif will be installed by default and I don't see why zif cannot be command line compatible with Yum. If you are going to make compatibility so important as to read yum.conf and yumdb datebase, this seems a far more trivial thing to do. I could set a alias locally if I prefer Zif and not have to relearn the commands.
Is that an answer to my last paragraph? If so: Installing the zif command line by default or not is really an implementation detail. But IMHO zif.conf not being noreplace really needs fixing. That said, even without that fixed, kicking out zif for no other reason than "it's not yum" is just plain unacceptable.
(And FWIW, rhughes has already responded to both of my bug reports and is addressing them.)
Replying to [comment:10 sundaram]:
...I don't see why zif cannot be command line compatible with Yum.
It pretty much is already. Just type "zif" to see all the command aliases and the runtime switches.
Replying to [comment:7 rhughes]:
Replying to [comment:5 james]: It's far past time to bring package management inline. By that, I guess you mean "we have to remove anything doing package management that isn't yum" Newsflash at 10: Yum doesn't work very well in multithreaded interactive programs written in C. For example, you can't "fix" yum to allow multiple locks so you can still read the rpmdb while you're downloading packages. Not allowing that makes we're sitting in a GUI program staring at a little spinner saying "Waiting for package manager lock". The designers hate it, the users don't understand it and it doesn't even work for me half the time. People also don't understand why we have to download all 300 Mb of packages before we can start installing updates and I don't understand this as a limitation either if each subtransaction is depsolvable. Basically yum isn't designed for this use case, and that's perfectly fine; yum works really well on the command line for administrators and wasn't designed to be low-latency and multithreaded. My real issue here, is that the yum backend in PackageKit is unmaintained. I'm the only one that keeps things limping on and twice now I've been screwed when the yum API has changed without anyone telling me. Once just caused a regression, and once it caused a security CVE. I can't read the yum developer API docs, because there aren't any. To learn about yum I have to read the source code, and try to work out what's going on. When yum starts interacting with RHN, things get very "magic" indeed, and I'm pretty sure nobody understands really what is going on. Unless the yum maintainers actually maintain the yum interface code in PackageKit (I've asked for help both publicly, and internally at Red Hat) and start to add features that I need for the desktop use case I don't see why I shouldn't develop something that does address the different use-cases we have for the desktop. After all, if PackageKit sucks, it's me that looks bad.
The main problem with the yum PK backed, it that PK want to do thing in different way that the way yum does things, so it is very hard to make the ends fit. But there is no problem making a GUI on top of yum, you just have to do thing in a way there match the way the lower part of yum and rpm is working. It is hard to do things asynchronous, when they are synchronous by nature.
Replying to [comment:14 timlau]:
you just have to do thing in a way there match the way the lower part of yum and rpm is working.
In GNOME3, all the development is being let by UI designers. Designers don't care how things work in the lowest layers of the system, they just want things to work.
Replying to [comment:9 kkofler]:
Due to intentional incompatibility Zif is not being incompatible at all. It's trying hard to be compatible, and the yum developers are the ones who forced zif to turn off some of its compatibility features (yumdb access, yum.conf parsing).
I is very bad to mess with an applications private data behind the scene, you must use the applications api to do so.
The real reasons for zif are all spelled out on [http://people.freedesktop.org/~hughsient/zif/]. Yum is just not suitable for !PackageKit's needs. This will create dependency and compatibility problems and worse yet,confusion for our users. We've encountered this problem in the past with apt-rpm and smart. Nonsense, apt-rpm worked just fine until the big RPM API cleanup broke it. I haven't tried it lately because I'm now using KPackageKit, which doesn't have an apt-rpm backend, but AFAIK apt-rpm is working fine again. Time was difference back then there was no yum history db and yum db back then and if you was using apt-get, you would stick with that not using 2 package manager at the same time. It would be best if yum-incompatible depsolvers be removed from the default set of pkgs (either explicitly or by dep). Those depsolvers are not yum-incompatible, they can coexist just fine with yum. You can realistically have two users of a Fedora machine using two different editors, or GUIs. You can also realistically use 2 different depsolvers at the same time on the same machine, e.g. yum or apt-rpm for command-line operation and zif for !PackageKit. It will just work, as long as the RPM layer is shared. And as I wrote on the mailing list: If we were to keep only one depsolver, once zif is stable, which one would we want to keep: * the tool written in a slow interpreted language, which cannot even be loaded into the process of the backend for our default package management GUI, requiring complex hacks to be spawned out of process and to bridge the language gap, or It is no yum's fault, that PK is design in a way that makes it hard to make a good yum backend, I have made most of it, so I know it the hard hay. the tool written in the same compiled language as our default package management GUI (and its backend daemon) and by the same primary developer, which can be loaded simply as a shared library? Yum is way older than pk and yum don't get redesigned and re-written i C because someone whats to write a gui i C. I know you want your own code to be used, but let's be honest… Yum's reliance on Python is a major design flaw causing several problems for Fedora: * depsolving slowness and memory use (e.g. I'm sure Python is to blame for a significant part of Anaconda's skyrocketing memory requirements; !PackageKit update checks through yum are also a huge CPU and memory hog etc.), Python/yum is not slow and the memory requirement is because of the huge number of packages and metadata there need to be handled in Fedora. * making Python (a huge interpreter) part of the critical path, Python is bad, C is better is a lame argument, lot of Fedora is made in Python, It is much easier to maintain and is much better to handle complex datastructures. * upgrade issues like the infamous "yum from F10 updates has a higher EVR than yum from F11 GA, but is built against the old Python and won't run on F11" issue which was a PITA to recover from, I cant see what that was to do with anything, there has been a lot of there bump issues in the Fedora history is more about update policies than about yum. * inability to be loaded as a shared library into compiled programs like the !PackageKit daemon, It is not yum's fault that PK is designed that way, you turn things upside down. * relying on the deprecated Python 2 and slowing down Python 3 adoption. Python 2.x is not deprecated and with live for a very long time, then mayor problem with python 3 and yum is evey things that uses yum has to be converted at the same time (Koji, mash, anaconda etc) and there is no big benefits from switching to a new language (Yes, P3 is kind of a new language) (And to be honest, the attitude of the yum developers personally makes me want to switch to !PackageKit-zif (and back to apt-rpm for those cases where I need a command line) ASAP.)
Nonsense, apt-rpm worked just fine until the big RPM API cleanup broke it. I haven't tried it lately because I'm now using KPackageKit, which doesn't have an apt-rpm backend, but AFAIK apt-rpm is working fine again. Time was difference back then there was no yum history db and yum db back then and if you was using apt-get, you would stick with that not using 2 package manager at the same time.
If we were to keep only one depsolver, once zif is stable, which one would we want to keep: * the tool written in a slow interpreted language, which cannot even be loaded into the process of the backend for our default package management GUI, requiring complex hacks to be spawned out of process and to bridge the language gap, or It is no yum's fault, that PK is design in a way that makes it hard to make a good yum backend, I have made most of it, so I know it the hard hay.
Yum is way older than pk and yum don't get redesigned and re-written i C because someone whats to write a gui i C.
Yum's reliance on Python is a major design flaw causing several problems for Fedora: * depsolving slowness and memory use (e.g. I'm sure Python is to blame for a significant part of Anaconda's skyrocketing memory requirements; !PackageKit update checks through yum are also a huge CPU and memory hog etc.), Python/yum is not slow and the memory requirement is because of the huge number of packages and metadata there need to be handled in Fedora. * making Python (a huge interpreter) part of the critical path, Python is bad, C is better is a lame argument, lot of Fedora is made in Python, It is much easier to maintain and is much better to handle complex datastructures. * upgrade issues like the infamous "yum from F10 updates has a higher EVR than yum from F11 GA, but is built against the old Python and won't run on F11" issue which was a PITA to recover from, I cant see what that was to do with anything, there has been a lot of there bump issues in the Fedora history is more about update policies than about yum. * inability to be loaded as a shared library into compiled programs like the !PackageKit daemon, It is not yum's fault that PK is designed that way, you turn things upside down. * relying on the deprecated Python 2 and slowing down Python 3 adoption. Python 2.x is not deprecated and with live for a very long time, then mayor problem with python 3 and yum is evey things that uses yum has to be converted at the same time (Koji, mash, anaconda etc) and there is no big benefits from switching to a new language (Yes, P3 is kind of a new language)
Your attitude is kind of hostile too, You are free to switch to what ever you want as long as you now what you are doing and can work around your own problems. But you are not the one who have to deal with all there bugzilla reports there will come from lesser skilled people there have messed up there systems.
I fully support Elad's [https://fedoraproject.org/wiki/Features/ZifByDefaultForDesktop] proposal. That said, I would personally like [https://bugzilla.redhat.com/show_bug.cgi?id=739282] and probably [https://bugzilla.redhat.com/show_bug.cgi?id=739283] addressed before zif becoming the default. I do not, it will be very bad for Fedora is you use two package manager in parallel, that don't do the same stuff. I will be a QA and bug tracker nightmare.
Replying to [comment:16 timlau]:
It is no yum's fault, that PK is design in a way that makes it hard to make a good yum backen
I'm not saying that it is the fault of yum; it was never designed to be multithreaded and used in asynchronous cancellable GUI programs. My whole argument is that you can't design a library to be good at everything. Zif makes sense for the "I don't care, just make it work" user experience the designers want and yum makes sense for sysadmins sitting on a console. Different use-cases, different tools.
Sorry for the previous post, and any mental snafus here ... trac lost my post and I had to write it again.
Replying to [comment:5 james]: It's far past time to bring package management inline. By that, I guess you mean "we have to remove anything doing package management that isn't yum"
Again, you shouldn't have two package managers anymore than you should have two kernls or glibcs ... if the answer isn't yum, that's fine.
As you know the yum developers and our users have been repeatedly burned because you arbirarily decided to disable certain yum plugins in PK, instead of fixing broken assumptions in PK. And that was mostly just a single plugin, which not many users have installed. Having two seperate package managers is going to be 1000x times worse than that.
Every single bug about packaging will have to be "triaged" about "is it about X, or Y or X+Y" ... with a huge number being closed "sorry, you just got screwed by us having more than one package manager".
I will admit to thinking that zif is slow, buggy and very feature poor compared to yum ... so would be a bad choice. But in many ways my quality of life will improve significantly if "the powers that be" choose it instead.
Newsflash at 10: Yum doesn't work very well in multithreaded interactive programs written in C.
Not much does, including rpm, curl and sqlite. But I'm not sure how that's relevant.
For example, you can't "fix" yum to allow multiple locks so you can still read the rpmdb while you're downloading packages.
You can certainly have yum look at the rpmdb and download packages ... you just don't do it from a single process with threads and locks.
People also don't understand why we have to download all 300 Mb of packages before we can start installing updates and I don't understand this as a limitation either if each subtransaction is depsolvable.
Indeed, which is why that's on the TODO list to be fixed ... and there have been several proof of concepts to allow that in yum.
Of course it doesn't help when people who have the time and motivation to do that feature decide to rewrite the world instead.
My real issue here, is that the yum backend in PackageKit is unmaintained.
I appologize that learning to work with an existing code base is harder that writing your own code ... I'm not sure what I can do to change that though.
I'm the only one that keeps things limping on and twice now I've been screwed when the yum API has changed without anyone telling me. Once just caused a regression, and once it caused a security CVE.
As I've said before, the yum API has never changed and we don't have any plans on changing it. In fact we've even changed things around internally to match weird assumptions that callers have made ... when we've know about them.
I can't read the yum developer API docs, because there aren't any.
There has always been docs, and more recently there has been work to make the prettier and web available:
http://yum.baseurl.org/api/
...and we've (the yum developers) have always been available to help people. It's hard to attribute statements like this to pure ignorance.
To learn about yum I have to read the source code, and try to work out what's going on. When yum starts interacting with RHN, things get very "magic" indeed, and I'm pretty sure nobody understands really what is going on.
I appologize that learning to two seperate code bases is even harder than learning one which is harder than writing your own code ... I'm not sure what I can do to change that though.
The last thing you said to me was roughly "I'm never going to speak to you again unless I'm forced to, and I'm never going to open any BZs about changes I'd like in yum".
Also my understanding is that Phil had suggested the packaging group take over teh yum PK backend, and has been reincentivised by recent events to move that forward. So you might want to talk to him.
Replying to [comment:17 rhughes]:
Replying to [comment:16 timlau]: It is no yum's fault, that PK is design in a way that makes it hard to make a good yum backen I'm not saying that it is the fault of yum; it was never designed to be multithreaded and used in asynchronous cancellable GUI programs. My whole argument is that you can't design a library to be good at everything. Zif makes sense for the "I don't care, just make it work" user experience the designers want and yum makes sense for sysadmins sitting on a console. Different use-cases, different tools
I'm not saying that it is the fault of yum; it was never designed to be multithreaded and used in asynchronous cancellable GUI programs. My whole argument is that you can't design a library to be good at everything. Zif makes sense for the "I don't care, just make it work" user experience the designers want and yum makes sense for sysadmins sitting on a console. Different use-cases, different tools
This is true for an editor or a GUI for a package manager, but in the bottom there is only system, so you need to use only package manager to keep the system state consistent an keep an exact history of what has applied to the system else it is impossible to find out what did go wrong, when something breaks. It like using both deb and rpm on the same system. Even when there is only one package manager it very hard to handle all the strange cases with the amount of packages and packagers in Fedora and introducing a new one will hurt the "I don't care, just make it work" most because they do not always know the what they are doing and will just copy & paste some commands from a web forum and break there system and don't know how to fix it and all these kind of stuff will hit the package manager maintainer.
Leave personal matters out of this please.
I only want zif to be default backend to PK because of a UX issue. Not being able to search while installing, and search that takes more than 50 seconds are examples of a really bad UX.
Now, I don't really care about the implementation itself. Right now, zif provides the best UX for packagekit UIs. If it was possible with the yum backend, it would be good. But right now it isn't, and it seems to me that making the yum backend work well is a lot of work, while zif is already ready for the PackageKit use case.
About the dependency resolving approaches, there were some messages in the -devel list about writing a generic rpm dependency solver, that both yum and zif could use. If we had this, and both yum and zif will use it, it would solve the main issue you raise in this ticket.
Replying to [comment:20 james]:
...our users have been repeatedly burned because you arbirarily decided to disable certain yum plugins in PK, instead of fixing broken assumptions in PK
Quite the opposite I'm afraid.
The actual list is: rpm-warm-cache, remove-with-leaves, auto-update-debuginfo
I didn't arbitrarily decide anything, all the blacklisted plugins were in response to either bugs in bugzilla or reports on IRC.
Unless the yum maintainers actually maintain the yum interface code in PackageKit ... I don't see why I shouldn't develop something that does... The last thing you said to me was roughly "I'm never going to speak to you again unless I'm forced to, and I'm never going to open any BZs about changes I'd like in yum".
Unless the yum maintainers actually maintain the yum interface code in PackageKit ... I don't see why I shouldn't develop something that does...
No, that's not what I said at all.
AGREED: The RPM package installation GUI that is installed by default should use the same dependency solver/backend as the non-GUI default. (mmaslano, 18:22:16)
Replying to [comment:24 mmaslano]:
AGREED
So this isn't being discussed at the meeting after all? It's just being closed?
Replying to [comment:25 rhughes]:
This was indeed discussed at today's meeting. The logs are available here: http://meetbot.fedoraproject.org/fedora-meeting/2011-09-19/fesco.2011-09-19-17.01.log.html#l-315
That's not possible if the API is written in Python, and thus very hard to use from anything written in any other language. (It would mean linking in an embedded Python interpreter, or spawning a separate process. Both solutions suck.)
Plus, the problem is that you consider data which must be read and written to properly interoperate with yum to be "private". Then you argue that "Time was difference back then there was no yum history db and yum db back then", but that's a problem of your (plural) own making. (That said, zif currently cannot use the history DB. But it could use the yumdb, and you (plural) forced it not to.)
It is no yum's fault, that PK is design in a way that makes it hard to make a good yum backend,
Nonsense. It's not PK's fault that yum is designed in such a way that makes it hard to make a good yum backend for PK. PK is well-designed cross-distro C software, why should it be written in Python just because yum is a PITA to use from any other language? There are depsolvers out there written in Ruby or even bash, you can't suit them all.
Well, sorry, it does, that's exactly what zif is about.
upgrade issues like the infamous "yum from F10 updates has a higher EVR than yum from F11 GA, but is built against the old Python and won't run on F11" issue which was a PITA to recover from, I cant see what that was to do with anything, there has been a lot of there bump issues in the Fedora history is more about update policies than about yum.
You don't understand that this is a direct consequence of using Python? The fewer backwards-binary-incompatible dependencies you have, the more likely it is that a version built for Fedora n runs on Fedora n+1, and so you can use the Fedora n updates version to upgrade to the Fedora n+1 updates one when needed (a useful robustness property for a depsolver). Python is a notoriously backwards-binary-incompatible dependency.
Python 2.x is not deprecated
That's not what Python upstream says.
Newsflash at 10: Yum doesn't work very well in multithreaded interactive programs written in C. Not much does, including rpm, curl and sqlite. But I'm not sure how that's relevant.
zif downloads using libsoup, not curl. libsoup explicitly supports threaded programs.
Replying to [comment:24 mmaslano] (who's only the messenger):
While I see where FESCo is coming from in principle (I read the relevant part of the log), in practice, that decision will probably mean either forcing zif onto everyone and making the command-line users unhappy, or continuing forcing yum onto everyone and making the !PackageKit users unhappy. :-(
I'd personally like to see zif evolve to a point where it'll also make the command-line users happy, even if it means growing some features !PackageKit will never need (note that that's my personal wish and that I'm not a zif developer, at least at this time), but I think it's a mistake to make this a requirement for using zif in !PackageKit. !PackageKit should use the depsolver that suits it best, and it should be neither FESCo's nor the command line users' business to tell it what depsolver to use, as long as it works and interoperates with the rest of Fedora (but zif does that).
Replying to [comment:24 mmaslano]: AGREED So this isn't being discussed at the meeting after all? It's just being closed? We discussed it and it was closed with: AGREED: The RPM package installation GUI that is installed by default should use the same dependency solver/backend as the non-GUI default.
So this isn't being discussed at the meeting after all? It's just being closed? We discussed it and it was closed with: AGREED: The RPM package installation GUI that is installed by default should use the same dependency solver/backend as the non-GUI default.
It doesn't say that you can't add some simple dialog to switch to zif, but in main setting it must be use yum. I'm sorry this solution probably disappoint many users.
Replying to [comment:27 kkofler]:
Replying to [comment:24 mmaslano] (who's only the messenger): AGREED: The RPM package installation GUI that is installed by default should use the same dependency solver/backend as the non-GUI default. (mmaslano, 18:22:16) While I see where FESCo is coming from in principle (I read the relevant part of the log), in practice, that decision will probably mean either forcing zif onto everyone and making the command-line users unhappy, or continuing forcing yum onto everyone and making the !PackageKit users unhappy. :-( I'd personally like to see zif evolve to a point where it'll also make the command-line users happy, even if it means growing some features !PackageKit will never need (note that that's my personal wish and that I'm not a zif developer, at least at this time), but I think it's a mistake to make this a requirement for using zif in !PackageKit. !PackageKit should use the depsolver that suits it best, and it should be neither FESCo's nor the command line users' business to tell it what depsolver to use, as long as it works and interoperates with the rest of Fedora (but zif does that).
Kevin, I'm also missing C library with nice API. We run into problems during rebuild of Perl and I guess rel-engs have same problems. Different tools have to implement some part of depsolving or version comparison again and again with different bugs. Currently, I'm waiting what will happen with libsolv library developed by SUSE.
Login to comment on this ticket.