On 12/01/16 01:47 -0800, Ed Marshall wrote:
Bringing this discussion to the mailing list, since it's all apparently
happened in bugzilla until now (and I only found out when I updated this
evening).
For reference: https://bugzilla.redhat.com/show_bug.cgi?id=1282825
This update (0.4.3 to 2.0.0) went out today, for both F22 and F23. It
removes the ability to edit KeePass 1.x databases, and offers only a
one-way import to 2.x databases. This breaks anyone depending on the
ability to sync databases between devices mid-release.
How is this possibly the correct thing to do for users in the middle of a
release cycle? Could a keepassx2 package not have been pushed out, or
barring that, a copr for the updated package for people to try out on their
own if they need it today? Shouldn't breaking changes like this wait for
release boundaries? (Isn't that why we have relatively short release cycles
in the first place?)
I'm concerned by this update too.
The latest post in Bugzilla says:
(In reply to Francesco Frassinelli (frafra) from comment #35)
(In reply to Ed Marshall from comment #33)
> (and, obviously, send email to the mailing list, so users are
> actually
> notified this time rather than getting a surprise breaking upgrade
> out of
> the blue)
I can't downgrade keepassx because many people upgraded their
database
(comment #34).
Those people are presumably happy with version 2 (or are stuck with it
now). But there are other people refusing to upgrade because of this.
A possible solution is to include both keepassx-0.4.4 and
keepassx2-2.0.0 in F22 and F23, so people can choose which version to
use based on their preference (and whether they've already upgraded
their databases).
I could provide a keepassx2 subpackage which replaces keepassx =
2.0.0, but
I'm not sure about how to handle Obsoletes/Provides in this case.
Couldn't both be installed at the same time (if the binaries are
renamed)? You just can't use the same .kdb file with both versions.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
