KeepassX2 was submitted for review: https://bugzilla.redhat.com/show_bug.cgi?id=1326875

I've also offered to post builds for particular releases and archs as requested.

The problem as I understand it is that the packages were updated in such a way as to modify the internal database format of the key storage and then were later downgraded again in such a way as to make their database of keys unreadable (unless they reverted to the 2.x version of the RPM).

The initial upgrade to 2.x was unacceptable due to the database change in a stable release, but as that has already happened, there's nothing left to be done about it. Downgrading to 0.x and breaking compatibility with the upgraded databases is far worse, since anyone who has been updating continuously through this process will be left broken with no obvious way to recover.

It seems to me that the only sane approach now is for the keepassx package to remain on version 2.x and for the newly-created package to be the 0.x version instead and for it to include Obsoletes: keepassx < 2.0 so that anyone still on the old version of keepassx will upgrade to keepassx0x (or however you name it).

For the record, I just confirmed with the DNF folks that the Obsoletes: keepassx < 2.0 approach should work properly as I suggested above.

I can see the logic there, but when I crafted the keepassx2 package for review I was also thinking of EPEL, where it would be similarly unacceptable to upgrade keepassx to 2.x. Given keepassx = 2.0.x and keepassx0x = 0.4.4, how would we get keepassx 2.x in EPEL without an additional keepassx2 package?

In a perfect world keepassx would never have been updated to 2.x, at least in stable releases, but it was. None of the options for correcting the situation are good. I'd prefer to push the 0.4.4 updates for keepassx and add keepassx2 to the repos, but I'll obviously abide by whatever FESCO decides.

Replying to [comment:1 limb]:

KeepassX2 was submitted for review: https://bugzilla.redhat.com/show_bug.cgi?id=1326875

I've also offered to post builds for particular releases and archs as requested.

After 3 months, all KeePassX users moved to 2.0 database type, so they are not expected to know that a keepassx2 package will be released

Replying to [comment:2 sgallagh]:

It seems to me that the only sane approach now is for the keepassx package to remain on version 2.x and for the newly-created package to be the 0.x version instead and for it to include Obsoletes: keepassx < 2.0 so that anyone still on the old version of keepassx will upgrade to keepassx0x (or however you name it).

Did you mean to create a new (and different) package keepassx-0.4 ? IMHO is a waste of work and time, since in 3 months all F23 KeePassX users probably already migrated to 2.x database type

Replying to [comment:4 limb]:

I can see the logic there, but when I crafted the keepassx2 package for review I was also thinking of EPEL, where it would be similarly unacceptable to upgrade keepassx to 2.x. Given keepassx = 2.0.x and keepassx0x = 0.4.4, how would we get keepassx 2.x in EPEL without an additional keepassx2 package?

So I see two potential solutions:
1) You just treat EPEL as a special case and keep keepassx on the 0.x version and introduce a new package. You then lose the ability to trivially backport updates around, but EPEL continues without change.

2) You abandon the keepassx name on both Fedora and EPEL and go to keepassx0 and keepassx2 for both, using Obsoletes to migrate people to the appropriate new name. Then you retire the old keepassx from both EPEL and Fedora. You end up with some slightly ugly package names, but you get back to being able to do easy backports.

In a perfect world keepassx would never have been updated to 2.x, at least in stable releases, but it was. None of the options for correcting the situation are good. I'd prefer to push the 0.4.4 updates for keepassx and add keepassx2 to the repos, but I'll obviously abide by whatever FESCO decides.

Yeah, like I said: we can't turn back history, so let's see how to move forward and not dwell on that.

Replying to [comment:5 germano]:

Did you mean to create a new (and different) package keepassx-0.4 ? IMHO is a waste of work and time, since in 3 months all F23 KeePassX users probably already migrated to 2.x database type

This is necessary because we have to cover the cases where
* Some users update very infrequently due to limited network access
* Some people will be upgrading from F22 at various times.

So we need to have a path for people that still have 0.x installed.

Replying to [comment:6 sgallagh]:

Replying to [comment:4 limb]:

I can see the logic there, but when I crafted the keepassx2 package for review I was also thinking of EPEL, where it would be similarly unacceptable to upgrade keepassx to 2.x. Given keepassx = 2.0.x and keepassx0x = 0.4.4, how would we get keepassx 2.x in EPEL without an additional keepassx2 package?

So I see two potential solutions:
1) You just treat EPEL as a special case and keep keepassx on the 0.x version and introduce a new package. You then lose the ability to trivially backport updates around, but EPEL continues without change.

I would prefer this option. It is less impact on Fedora overall, and it doesn't involve EPEL unnecessarily in something that only happened in Fedora.

2) You abandon the keepassx name on both Fedora and EPEL and go to keepassx0 and keepassx2 for both, using Obsoletes to migrate people to the appropriate new name. Then you retire the old keepassx from both EPEL and Fedora. You end up with some slightly ugly package names, but you get back to being able to do easy backports.

This has a rather confusing and negative impact for both EPEL and Fedora users. I don't see how it would be better than option 1.

In a perfect world keepassx would never have been updated to 2.x, at least in stable releases, but it was. None of the options for correcting the situation are good. I'd prefer to push the 0.4.4 updates for keepassx and add keepassx2 to the repos, but I'll obviously abide by whatever FESCO decides.

Yeah, like I said: we can't turn back history, so let's see how to move forward and not dwell on that.

Agreed.

As an aside, I think it's simply folly to believe packages in Fedora and EPEL can be treated similarly. The are distinct things with distinct lifecycles and rules. The only commonality is the infrastructure used to build them. Sometimes I think maintainers are lulled into a false sense of sameness by that, but we can't really avoid it without duplication of infrastructure.

Jon, how are you feeling about this suggestion? Will this work as a solution for you or do you need FESCo to make it official? Do you have reservations about the proposed approach?

Meaning update keepassx back to 2.0.2 and create keepassx0x, with keepassx2 as EPEl-only?

Yes, exactly (with the Obsoletes: to aid existing users)

Not thrilled, but not really much less thrilled than with the status quo, so I'll do it.

Can you detail how the obsoletes should work? I assume nothing for keepassx2 in EPEL, but what for each of keepassx and keepassx0x?

I ''think'' this is what we want, but please test it before pushing :)

== Fedora ==
=== keepassx ===
{{{
Epoch: 1
Version: 2.0.0
Release: 2
}}}
=== keepassx0 ===
{{{
Epoch: 0
Version: 0.4.4
Release: 1
Obsoletes: keepassx < 0:2.0
}}}
Note: This means that anyone currently on keepassx version 1:0.4.4 will be upgraded to 1:2.0.0. This is ''intentional'', since we can only reasonably assume that they passed through the intermediate 0:2.0.0 stage and this will unbreak them. It's not perfect, but it's the best we can do.

== EPEL ==
=== keepassx ===
No change

=== keepassx2 ===
Created as normal. This should be designed to co-exist harmlessly with keepassx (such as not automatically converting files; if this conversion desired it should be an intentional action on the part of the user).

Ok sounds good. The trick will be changing the keepassx 0.4.x build to be parallel-installable with keepassx 2.x. Changing 2.x was fairly simple.

Any status update on this? Let us know if you're blocked on a stalled package review or anything.

Jon, what's the status here, please? Do you need someone to step in and do this for you?

Sorry for the delay, my problems do not include a stalled review, but they do include making the two parallel installable and a dearth of time due to a job change. I was able to easily modify 2.0.x to be keepassx2, but 0.4.x doesn't seem to be as adaptable. I can probably get to it in the next week or so, but if a faster resolution is needed I can post what I have.

Ok, here's the keepassx0 review: https://bugzilla.redhat.com/show_bug.cgi?id=1340269

I've got the changes to keepassx for 2.x ready to go once it's approved, and the EPEL-only keepassx2 review is nearly done.

ping here? any movement here? keepassx2 is approved for EPEL.

I did the review for keepassx0 and sent it back to fix a few minor issues. I haven't seen any movement since then. If someone else wants to take over and fix up those last few bits for Jon, I'll be happy to do the second pass of the review.

The F24 "update"
https://bodhi.fedoraproject.org/updates/FEDORA-2016-139a37787e
has not been unpushed, so it damaged F23->F24 upgrade as you can see from the following bugreport.
https://bugzilla.redhat.com/show_bug.cgi?id=1343064

I would like also to know why the "upgrade"'s Type has been marked as "Security"

Thanks everyone, I'm importing and building everything now.

The reason these were marked as Security is because they were updates to 0.4.3, which had a security flaw.

All builds submitted in bodhi. Thanks all, and sorry for the mess!

At the risk of annoying everyone:

In Fedora 23 updates, right now, the keepassx package is at keepassx-2.0.0-1.fc23.x86_64. It contains a binary called /usr/bin/keepassx.

In contrast, keepassx-1:2.0.2-1.fc23.x86_64 does not contain /usr/bin/keepassx at all. (In fact, nothing in updates-testing provides /usr/bin/keepassx.) This means that a Fedora 23 user who updates if keepassx-1:2.0.2-1.fc23.x86_64 becomes stable will have no /usr/bin/keepassx2 binary at all. I think this is a pointless regression for command-line or Alt-F2 users.

Furthermore, in Fedora 24, we're currently slated for /usr/bin/keepassx not to exist.

limb says (https://bugzilla.redhat.com/show_bug.cgi?id=1338054#c13) that this is what FESCO wants. I think that FESCO was clear as to what it wanted re: the package versions, but I think it's entirely unclear from this FESCO ticket what the actual supplied binaries should be.

I suggest that /usr/bin/keepassx be added as a symlink to /usr/bin/keepassx2.

IMHO this isn't something for FESCo to micromanage, and should be up to the maintainer.

Personally I agree something (probibly the new keepassx2) should have the /usr/bin/keepassx name, but it sounds like limb doesn't understand what people are asking for. I've added my thoughts to the bug.

I understood, I just hadn't made up my mind. I'll add /usr/bin/keepassx to keepassx 2.0.2.

Update incoming.