#1148 F20 System Wide Change: Application Installer - https://fedoraproject.org/wiki/Changes/AppInstaller
Closed None Opened 10 years ago by jreznik.

For the 2013-07-24 meeting as the Change Proposal was announced on devel-announce list on 2013-07-10 as Self Contained Change. Escalated to System Wide, requested details were updated.

https://lists.fedoraproject.org/pipermail/devel/2013-July/185025.html


(Note: Missing next week's meeting, commenting here.)

As written, this feature breaks the existing policy of all tools using the same packaging backend.

If there is general agreement that we would be shipping hawkey/dnf in the future (which I presume there is), I could consider this assuming the hawkey team is OK with it being used this early. But I would be concerned about how the hawkey/yum/rpm lock interactions work.

+0 for now - I'd like to discuss it in the meeting.

Replying to [comment:1 notting]:

But I would be concerned about how the hawkey/yum/rpm lock interactions work.

Both yum and hawkey use librpm, which use the low level rpm lock. So if you tried to do a rpm -Uvh foo.rpm when PackageKit or the yum CLI are in operation, then it would just wait for the rpm lock to be cleared just like before. The metadata store is in a different place by default (PackageKit manages it's own cache now to avoid 'downloading metadata' in odd places), so we don't have to worry about metadata locks (or a global lock) at all.

Right now my vote is "defer for more discussion/information (or -1 with status as of today)".

I think the policy from https://fedorahosted.org/fesco/ticket/669#comment:24 is, in principle, right; but if the packaging tools team and application installer developers agreed on an exception, I'd defer to them.

I can see the following alternatives:
1. We move everything to hawkey/dnf now. (Rejected by Jan Zelený.)
2. Packaging team agrees to have Application Installer as the default GUI using hawkey now.
* In this case I'd really want to have a fairly specific idea of when and how the yum/hawkey duplication will be resolved. I'd like to avoid another !NetworkManager-like situation.
* Functionality-wise, if hawkey/dnf isn't ready now, it's unclear that it is ready for the Application Installer.
* I've been told that using hawkey now would mean breaking some yum functionality (yumdb isn't updated by dnf/hawkey), which sounds rather unpleasant.
* But again, I'd defer to a consensus of the two groups, if any.
3. Application Installer is available in the repository in F20, uses hawkey, but the default package GUI remains yum-based !PackageKit. This would mirror the current hawkey situation (explicit users' choice is required to use the new backend), and is therefore similarly acceptable.
* "Default package GUI" means that in the default installation (and the GNOME spin) 1) it is (the only alternative) available in the menu 2) desktop notifications and other parts of the desktop (control-center) use it 3) file associations, if any, use it.
4. Application Installer in F20 uses a yum backend, moving to hawkey later with the rest of the system.
5. Application Installer is deferred entirely until hawkey becomes the default, and we continue to use !PackageKit until then.

Finally, it's not clear to me that the infrastructure aspects (new metadata?) are agreed upon. That can be resolved either by fleshing out the plan in sufficient detail now, or by providing a realistic and practical contingency plan (and a deadline when to enact it).

Replying to [comment:4 mitr]:

Finally, it's not clear to me that the infrastructure aspects (new metadata?) are agreed upon. That can be resolved either by fleshing out the plan in sufficient detail now, or by providing a realistic and practical contingency plan (and a deadline when to enact it).

Rereading the current contingency plan for this case - as long as the contingency "degrated experience" fulfills our release criteria and isn't "obviously broken", that contingency plan is good enough for me.

We already decided similar ticket #699: "The RPM package installation GUI that is installed by default should use the same dependency solver/backend as the non-GUI default."

I do not think we can once deny such request and approve it next time for different software.

I would agree with jzeleny alternative no. 3 (Application Installer is available in the repository in F20, uses hawkey, but the default package GUI remains yum-based PackageKit). Otherwise no. 4.

-1 until rework of change, which would take into account one of mentioned proposals.

https://lists.fedoraproject.org/pipermail/devel/2013-July/185402.html is jzeleny's last post on the subject. Seems to be leaning towards not wanting the defaults to be to use a hawkey backend at this time but is fine for a hawkey backend to be optional and selectable for early adopters to test. @jzeleny: Is that correct?

A related issue is whether we're making as strong guarantees about not breaking the hawkey backend as we're making with yum (due to that being how we'd want to deliver any fix in the first place). In the past, I'm not sure whether we've included the graphical package manager in those guarantees or only the CLI version. Since part of this Change is to split to having both a package manager and an application manager I'm not sure if we also want to make guarantees about one of each of those.

Replying to [comment:7 toshio]:

https://lists.fedoraproject.org/pipermail/devel/2013-July/185402.html is jzeleny's last post on the subject. Seems to be leaning towards not wanting the defaults to be to use a hawkey backend at this time but is fine for a hawkey backend to be optional and selectable for early adopters to test. @jzeleny: Is that correct?

Not quite. I was leaning towards this solution only because of the existing policy. That being said, I'm perfectly fine having two interfaces using two different depsolvers. The result will be the same for both of them in vast majority of cases. Also note that if the result is different, the dependencies themselves will never get broken.

Taking that into consideration, the only potential problem lies in the fact that dnf doesn't update yumdb and I assume PK using hawkey will behave the same way. Again, in most of the cases this will be fine because yum does check rpmdb for the necessary information. The only functionality that won't work is automatic removal of packages installed as dependencies - yum will think that all packages installed through PK w/ hawkey and dnf were installed explicitly, it won't distinguish between explicit installation and dependencies.

"3. Application Installer is available in the repository in F20, uses hawkey, but the default package GUI remains yum-based PackageKit."

This does not work. The application installer is not just "a GUI" that can be optionally installed or not. It integrates with the handling of updates in the rest of the desktop. E.g, we want it to be launched when you click on a 'Updates available' notification.

I can't believe that you are really arguing for keeping gpk-update-viewer/gpk-application the "default package GUI". These UIs are not up to the task, we are getting ridiculed for them...

In that case we are getting into the situation that is against the current policy (as stated above) and FESCO needs to decide if this case deserves exception from the policy or rather if the policy makes sense at all. My personal opinion is that the policy can be dropped or at least an exception should be made.

Your comment also implies that my note about concurrent usage of yum and the app. installer still stands. I'm pretty sure the concurrent usage will be the case on many, if not all, desktop installations. No showstoppers in that scenario but I feel that the FESCO decision should be as informed as possible.

Replying to [comment:10 jzeleny]:

I'm pretty sure the concurrent usage will be

There are zero problems using the app installer/dnf/yum/zif at the same time. I've been doing it for a few weeks, and the hawkey backend uses a completely different metadata store. They all use librpm and share the rpm lock (which is a good thing) which means that there's no possibility of data corruption.

Richard

Replying to [comment:8 jzeleny]:

Taking that into consideration, the only potential problem lies in the fact that dnf doesn't update yumdb and I assume PK using hawkey will behave the same way. Again, in most of the cases this will be fine because yum does check rpmdb for the necessary information. The only functionality that won't work is automatic removal of packages installed as dependencies - yum will think that all packages installed through PK w/ hawkey and dnf were installed explicitly, it won't distinguish between explicit installation and dependencies.

What about (yum history), as the only place one can find out about rpm scriptlet failures?

Replying to [comment:9 mclasen]:

I can't believe that you are really arguing for keeping gpk-update-viewer/gpk-application the "default package GUI". These UIs are not up to the task, we are getting ridiculed for them...

All the world is not an UI. Replacing a broken UI with a different UI relying on an unfinished underlying mechanism and fragmenting the platform is not at all obvious to be an improvement.

(For the record, given jzeleny's comments, I'm provisionally +1.)

In answer to my second question:

A related issue is whether we're making as strong guarantees about not breaking the hawkey backend as we're making with yum

jreznick pointed me at this: http://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#Updates

So our (Fedora's) current expectations would seem to be that we won't break the GUI method of installing updates. With that in mind, @jzeleny & @rhughes, can we make that guarantee for hawkey in F20 and AppInstaller in general?

Replying to [comment:12 mitr]:

Replying to [comment:8 jzeleny]:

Taking that into consideration, the only potential problem lies in the fact that dnf doesn't update yumdb and I assume PK using hawkey will behave the same way. Again, in most of the cases this will be fine because yum does check rpmdb for the necessary information. The only functionality that won't work is automatic removal of packages installed as dependencies - yum will think that all packages installed through PK w/ hawkey and dnf were installed explicitly, it won't distinguish between explicit installation and dependencies.

What about (yum history), as the only place one can find out about rpm scriptlet failures?

True, that probably won't work as well. I have just learned that AppInst uses rpm directly to perform the installation. I guess this functionality needs to be implemented in the AppInst itself.

It is also important to point out that in the current state of things this wouldn't work (for the same reason) even if dnf was a default CLI installer in Fedora. Richard, any comments on the synchronization of yum/dnf and AppInst functionality?

Replying to [comment:15 jzeleny]:

Replying to [comment:12 mitr]:

What about (yum history), as the only place one can find out about rpm scriptlet failures?

True, that probably won't work as well. I have just learned that AppInst uses rpm directly to perform the installation. I guess this functionality needs to be implemented in the AppInst itself.

It is also important to point out that in the current state of things this wouldn't work (for the same reason) even if dnf was a default CLI installer in Fedora. Richard, any comments on the synchronization of yum/dnf and AppInst functionality?

Yes please - are we discussing a long-term tool discrepancy again, this time application installer/dnf instead of application installer/yum?

Replying to [comment:15 jzeleny]:

True, that probably won't work as well. I have just learned that AppInst uses rpm directly to perform the installation.

No, it uses PackageKit to do the install/remove.

Richard, any comments on the synchronization of yum/dnf

DNF doesn't write to the yumdb either from what I understand. When people proposed ZifByDefault a few releases ago, I was told that the yumdb is a private implementation of yum and is not a stable format. I had to remove the yumdb reading and writing in Zif just to get the Yum team to remove the conflicts: zif from yum.spec. Adding reading and writing to the yumdb is certainly possible to add in the timeframe, but I'll only do that if the yum team declare that that's okay.

Richard.

Replying to [comment:17 rhughes]:

DNF doesn't write to the yumdb either from what I understand. When people proposed ZifByDefault a few releases ago, I was told that the yumdb is a private implementation of yum and is not a stable format. I had to remove the yumdb reading and writing in Zif just to get the Yum team to remove the conflicts: zif from yum.spec. Adding reading and writing to the yumdb is certainly possible to add in the timeframe, but I'll only do that if the yum team declare that that's okay.

From my perspective, the correct place for storing information about software updates is the journal. That is what should replace the yumdb, not a reimplementation of this private db, or yet another private file.

Replying to [comment:18 mclasen]:

From my perspective, the correct place for storing information about software updates is the journal.

Works for me.

Richard.

Replying to [comment:17 rhughes]:

Replying to [comment:15 jzeleny]:

True, that probably won't work as well. I have just learned that AppInst uses rpm directly to perform the installation.

No, it uses PackageKit to do the install/remove.

That doesn't answer the question whether it goes through dnf or talks to rpm directly.

@rhughes: I understand your arguments. The situation AppInst vs. yum is however a bit different that dnf vs. yum. The dnf is a complete replacement of yum and therefore having its own database is correct. However AppInst will always have to coexist with either yum or dnf and right now connecting it with at least one of them is the missing piece in the puzzle.

Now, we can either say that we don't care about this use case and AppInst transactions won't be tracked in yum history or we have to find a way how to make them connected. Thinking long term here I'd prefer integrating the PK backend with dnf so the history is kept there. But in the short term we don't want our users to get frustrated by their yum history command not working.

To sum up everything into one question: would it be ok for you to implement a layer that would record AppInst transactions into yum and/or dnf databases? If the answer is yes, I don't think we have any other problem here and the feature can be approved with this implementation as a requirement.

@mclasen: I don't think we want to centralize this information in the journal. I have a bunch of reasons not to do it, I will give you just one that should be sufficient: there is also a lot of other information stored in yumdb that doesn't make sense storing anywehere else. Therefore yumdb/dnfdb is here to stay anyway so why not to use it and put all the SW management related information at one place?

Please, postpone this ticket to the next week, because there is needed discussion among jzeleny, hughsie, and maybe members of FESCo.

Thanks.

Replying to [comment:22 mmaslano]:

Please, postpone this ticket to the next week, because there is needed discussion among jzeleny, hughsie, and maybe members of FESCo.

Yes please, defer - it seems unlikely a plan will be agreed within the following 3 hours. (This retracts my provisional +1; I've now voted every possible way in this ticket :/)

Replying to [comment:21 jzeleny]:

Now, we can either say that we don't care about this use case and AppInst transactions won't be tracked in yum history or we have to find a way how to make them connected.

I'm happy reading and writing to the yumdb if the yum team are happy with this. I got in a lot of trouble when Zif started writing to it in the past, so I don't want to add support without at least a +1 from someone like zpavlas.

Thinking long term here I'd prefer integrating the PK backend with dnf

Ales and I have talked about this, and we agreed PackageKit using hawkey and librepo was a better idea than using dnf and having to go through C->python->C for every transaction.

Therefore yumdb/dnfdb is here to stay anyway so why not to use it and put all the SW management related information at one place?

The design of the yumdb is pretty horrific IMHO, but I've got code in Zif for this I can easily use in PackageKit. If I get a +1 for writing the yumdb, this is good for me.

Replying to [comment:21 jzeleny]:

@mclasen: I don't think we want to centralize this information in the journal. I have a bunch of reasons not to do it, I will give you just one that should be sufficient: there is also a lot of other information stored in yumdb that doesn't make sense storing anywehere else. Therefore yumdb/dnfdb is here to stay anyway so why not to use it and put all the SW management related information at one place?

Also, the vastly different lifecycle of journal entries would seem a bad idea for software management - you'd want much longer storage for them (likely indefinite, without admin intervention).

So, where are we? Waiting from a +1 for zpavlas?

  • AGREED: Approve the change conditional on 1) the packaging team and
    appinstaller both agreeing on a solution and writing the solution
    down, 2) the packaging team committing to maintaining the dnf stack
    so that updates are always possible; If the backend is not fully
    complete by alpha freeze, institute the contingency plan (+8, 0, 0)
    (sgallagher, 18:27:54)

Leaving open to track progress at alpha.

Sorry for the late response, we have extensively discussed the situation in the team to give you as accurate assessment of the situation as possible.

'''TL;DR version:'''[[BR]]
read the very last paragraph

'''Long version:'''[[BR]]
Our support of this project has not changed and the conditions stated in the FESCO agreement sound reasonable. That being said, we have some concerns and conditions ensuing from them which I'd like to state here for the record.

Basically we are worried about compatibility between yum and the old zif code which Richard plans to use in the new PK. As I understand it, the zif code is not compatible with yum and is therefore likely to cause a lot of troubles to users that use both yum and new PK backend on the same machine. ''That would be unacceptable for us.'' Also there is the issue of locking - if PK starts writing to yumdb, it has to adapt to yum's locking. An important observation is that ''a lot of testing'' would be required for the final version of this feature. Also with dnf replacing yum as default, we would be in the same situation once again.

As you can see, there is a lot of work for both developers and QA that needs to be done to achieve full compatibility. Unfortunately we don't have any resources to help with the compatibility in a short time frame, that's why we are targeting dnf for F22 in the first place.

'''We propose the following:'''[[BR]]
Our strong recommendation stays the same as it was from the very beginning, before this change was proposed: The Application Installer development should be coordinated with the dnf project and target release should be F22 instead of F20.

Because we anticipate this is not acceptable for authors of the Application Installer, we are willing to sign off the feature as long as ''100% compatibility'' with current yum functionality, including internal representation of entities in yumdb, is guaranteed by authors of Application Installer. This full compatibility must be thoroughly tested and signed off by Fedora QA before Beta Release of Fedora 20. It is important to note here that strict abidance of these conditions is very likely to cause the feature to slip to the next release anyway. Also it might be a good idea to talk to Fedora QA if they even have enough resources for the testing to happen.

I have to say I disagree with most of this.

'Full compatibility with yum' may be a goal for dnf, but it is a very explicit non-goal for the application installer. We want to get away from all the problems that yum has been giving us over the years. If we can't move beyond yum, then we can just drop this effort and accept that Fedora will never have a usable app installation story. I can refocus my resources elsewhere then.

The reason for the given requirement is so that the app installer doesn't corrupt state used by other parts of the system. If ensuring that is a 'non-goal' of the application installer, then yes, it's an impasse. Is that actually what you meant?

The reason for the given requirement is so that the app installer doesn't corrupt state used by other
parts of the system. If ensuring that is a 'non-goal' of the application installer, then yes, it's an
impasse. Is that actually what you meant?

If you consider the yumdb to be essential system state that must be maintained by everything that changes installed software, the you should also remove the rpm commandline client from the distro. Last I checked, it does not update yum history.

As far as I am concerned, as long as the yumdb is not accessible through a stable (non-python) api, it is just what its name says: it is the yum history. If it tool is not yum, its package changes will not show up in yums history. Anything else would be surprising. If it is meant to be a general 'software update history', then it needs to be available via a generally usable api, just like the journal.

Sure, we can kludge on some mechanism to write the to the yumdb. It'll get bogged down with locking and will be fragile and frustrating to the users of the app installer.

I was going off of Richard's statements about writing to the yumdb - in the case where AppInstaller writes to the yumdb, I think it's a perfectly reasonable requirement that it behave in a manner compatible to other writers of that database, for obvious reasons.

If you are instead arguing that it should not write at all, that is a different argument than what he had proposed.

In any case, I would not read "packaging team has reservations about full support of the dnf stack two releases earlier than planned" as "can't move beyond yum".

Replying to [comment:28 jzeleny]:

Because we anticipate this is not acceptable for authors of the Application Installer, we are willing to sign off the feature as long as ''100% compatibility'' with current yum functionality, including internal representation of entities in yumdb, is guaranteed by authors of Application Installer. This full compatibility must be thoroughly tested and signed off by Fedora QA before Beta Release of Fedora 20.

Note that FESCo asked for the backend to be complete by alpha freeze (currently Sep 3); the above ("signed off by Fedora QA") would be an additional requirement.

Replying to [comment:32 notting]:

I was going off of Richard's statements about writing to the yumdb - in the case where AppInstaller writes to the yumdb, I think it's a perfectly reasonable requirement that it behave in a manner compatible to other writers of that database, for obvious reasons.

Sure, no disagreement.

If you are instead arguing that it should not write at all, that is a different argument than what he had proposed.

I'll talk to Richard before arguing further.

In any case, I would not read "packaging team has reservations about full support of the dnf stack two releases earlier than planned" as "can't move beyond yum".

Yeah, sorry. My wording was too strong here, I apologize. I'm just worried that we'll take the time until f22 to produce a perfect copy of yum, and then we'll end up with a perfect copy of yum...

''@mclasen:'' Please understand that keeping compatibility between all Software Management components is a key part of user experience for us (and I believe we are not the only ones). If you don't intend to honor that, our team disavows the proposal and it is up to FESCO to allow you breaking stuff.

I agree that yumdb is not an optimal piece of the system but that's not the point here. Yum has been a central SW management tool for a long time. If you want to change that now, you can't expect that to happen in a few months unless you want to break stuff. Please understand that we plan to improve the situation with the database in dnf and move the code from dnf to a separate library. But again, it will take some time and all Software Management components must play nicely and adopt this library before it's marked as default, otherwise we would break things.

''@mitr:'' I have no problem with alpha being the target release, I was just afraid that the aplha wouldn't be feasible for the developers of AppInst.

Replying to [comment:31 mclasen]:

The reason for the given requirement is so that the app installer doesn't corrupt state used by other
parts of the system. If ensuring that is a 'non-goal' of the application installer, then yes, it's an
impasse. Is that actually what you meant?

If you consider the yumdb to be essential system state that must be maintained by everything that changes installed software, the you should also remove the rpm commandline client from the distro. Last I checked, it does not update yum history.

Everyone that installs software uses librpm at some point. So if anything rpm should be the one that writes a history somewhere not yum.

And there are already multiple ways to install stuff that does not end up in the yum (non)database. smart, apt, zif, dnf ... and as mclasen said even rpm itself.

The central package management database is the rpmdb not the yumdb (which is application specific).

Where do we draw the line? Why doesn't yum write the downloads to my firefox download history? (Couldn't think of a better example but it should be good enough to show the point).

Replying to [comment:37 drago01]:

Everyone that installs software uses librpm at some point. So if anything rpm should be the one that writes a history somewhere not yum.

Not really, librpm is a low level API while yum contains the high level API. You can argue about the design decision itself but in the current design, the transaction database is on the right level of architecture.

And there are already multiple ways to install stuff that does not end up in the yum (non)database. smart, apt, zif, dnf ... and as mclasen said even rpm itself.

And in all these cases if you use those tools, you know very well what you are doing (or the one who gave you the instruction to do it), even in the case of rpm. In the case of AppInst the situation is exactly opposite.

The central package management database is the rpmdb not the yumdb (which is application specific).

In that case your project would be an optional complement of the default tool which is now yum and will be dnf. I have no problem with that whatsoever! But the original proposal was for this to become a default on desktop - not an option unless you either replace 100% of the default tool's functionality or be compatible with it.

Where do we draw the line? Why doesn't yum write the downloads to my firefox download history? (Couldn't think of a better example but it should be good enough to show the point).

This one is actually simple :-) yum is the default mechanism for Software Management in Fedora while Firefox is not the default downloading mechanism. If it was, we would consider the integration.

''Note: this will be my only response to this flame-bait, nothing has changed about the team's position regarding compatibility with yum.''

info mitr's proposal FESCo acknowledges comment#28 and asks feature owners to discuss this with Fedora QA. accepted +7:0:0

info Proposal: Further we ask packaging stakeholders to come up with a roadmap for dnf and yumdb and app installer items (the final state planned for ~F22). accepted: +6:0:0

FWIW, we had a chat about the history db thingie with Ales and Richard some time ago and the consensus was roughly:
1. Implement a common history database on top of eg. sqlite
2. Implement an rpm plugin which updates the history database, so all transactions are covered
3. Profit!

Details are sketchy/non-existent at this point, but I guess 1) would optimally be a library with an API of its own rather than "raw" sql access. 2) will require rpm >= 4.12 (which is nowhere near to being released) for the plugin interface, and could use some further librpm API enhancements for passing in relevant data (repository names and such which rpm itself has no clue about).

Given that none of the above exists yet AFAIK, obviously this is not going happen for F20.

Looking at FESCo meeting log from Aug 28th:

<notting> it wasn't clear to me whether panu's coment did or did not address gnome-software/zif writing directly to yumdb on an interim basis

<abadger1999> notting: I think it omits answering that question.

I see I failed to comment on a rather essential part of the future "roadmap", doh:
Before "profit", gnome-software/zif/dnf are to drop their own yumdb-equivalents and switch over to using the alleged common history database.

Replying to [comment:41 pmatilai]:

Looking at FESCo meeting log from Aug 28th:

<notting> it wasn't clear to me whether panu's coment did or did not address gnome-software/zif writing directly to yumdb on an interim basis

<abadger1999> notting: I think it omits answering that question.

I see I failed to comment on a rather essential part of the future "roadmap", doh:
Before "profit", gnome-software/zif/dnf are to drop their own yumdb-equivalents and switch over to using the alleged common history database.

To set the right expectations I'd like to stress that this is a future plan that's somewhere on the roadmap. It will not in any case make its way into Fedora 20, probably not even Fedora 21. Therefore the gnome-software is still required to write to yumdb in a way that's 100% compatible with yum code to protect integrity of the entire SW management stack. Otherwise we can't give it the green light.

Jan - Is 'yumdb sync' an acceptable way to do so?

Unfortunately that doesn't write to the transaction history so 'yum history' will not work.

Several questions were asked during the last meeting, with decision to revisit next week. Please reply, so FESCo can move on.

Based on the current status as described in Change Page.

<notting> does this include the yumdb bits in the PK hawkey backend?

<notting> so... what exactly happens with the version as currently packaged
in the absence of the metadata (icons, appdata, etc.)?

<abadger1999> jreznik: Question about the contingency plan -- are all of
those things being kept up-to-date? ie, if we need to revert to the yum
backend, we can "just do it"?

Then the discussion was about compatibility testing
<abadger1999> nirik: Okay -- so that sounds like, "ask the app installer
and packaging team if either are willing to write the needed test cases.
If not, then does the packaging team see an alternative to the 100% compat
testing or would they like to officially be against using the hawkey
backend?"

<notting> does this include the yumdb bits in the PK hawkey backend?

Yes, and I think I'm doing everything the same as yum now.

<notting> so... what exactly happens with the version as currently packaged
in the absence of the metadata (icons, appdata, etc.)?

At the moment I'm bundling the metadata with gnome-software; obviously not a great plan long term, but I'm written gnome-software in a way we could just shipping it on the mirrors whenever and it'll just use all the metadata from all the repos. We're still making changes to the metadata-generator, so it's possibly a good thing it's not running on koji just yet.

<abadger1999> jreznik: Question about the contingency plan -- are all of
those things being kept up-to-date? ie, if we need to revert to the yum
backend, we can "just do it"?

Yes, although yum keeps wanting to download things when we're not expecting it to. I've been using the yum backend for testing and although it's slow it certainly works.

<abadger1999> nirik: Okay -- so that sounds like, "ask the app installer
and packaging team if either are willing to write the needed test cases.

What would those test cases look like? I'm happy to run them, but I'm hardly the most neutral person to be writing them ;)

Richard.

Replying to [comment:47 rhughes]:

<notting> does this include the yumdb bits in the PK hawkey backend?

Yes, and I think I'm doing everything the same as yum now.

That's good to hear, is the current code available in the PK git repo[1]?

<abadger1999> nirik: Okay -- so that sounds like, "ask the app installer
and packaging team if either are willing to write the needed test cases.

What would those test cases look like? I'm happy to run them, but I'm hardly the most neutral person to be writing them ;)

Well, there is just a bunch of test cases that come to mind to cover the basic interoperability (from yum side it's about testing functionality like repo-pkgs, history, autoremove). But to be perfectly honest, I'd recommend a test day where users would try using the new PK/gnome-software together with yum as they'd use it on their system.

[1] git://gitorious.org/packagekit/packagekit.git

AGREED: Packaging team would be happy with properly publicized test day. No other action needed here (+7,-0,0)

There has been a development on this front. The Software management team had a discussion with Richard yesterday where we raised concerns about quality of the compatibility code in PK. Because the code cannot be revisited in time due to Richard's work load, we have all agreed that '''PK will keep using the old yum backend in F20''' and will switch to the new backend in F21. This solution should give us the time necessary to come up with a unified and clear database API.

The background is following: the old backend will slow the gnome-software significantly, that's why it was not preferred before. But the application is just a tech preview in F20, therefore it shouldn't be a problem atm. Users will still have the option to switch to the new backend manually (there is a switch for that when starting packagekitd).

Replying to [comment:39 toshio]:

info Proposal: Further we ask packaging stakeholders to come up with a roadmap for dnf and yumdb and app installer items (the final state planned for ~F22). accepted: +6:0:0

"Packaging stakeholders", when can we expect said roadmap? It's been 5 months now...

There are quite a few unknown variables at the moment but we are still on schedule. So far I can give you an outline:

  • May 2014: new Unified Software DB implemented
  • July 2014: the DB adopted in DNF
  • August 2014: DNF fully integrated into Anaconda
  • October 2014: all yum plugins ported to DNF
  • December 2014: DNF ready to take place of yum

I think we have a plenty of spare time in case something goes wrong, so F22 is still our target for the yum-dnf switch. Is this outline sufficient or did you want something more detailed?

Replying to [comment:52 jzeleny]:

Is this outline sufficient or did you want something more detailed?

The request included the app installer, which you haven't mentioned. (While the literal wording of the FESCo resolution doesn't say this, the intent was for all stakeholders to agree on a consistent plan, not to get individual plans that do not work together.)

Login to comment on this ticket.

Metadata