FS#55572 - [kile] 2.91.1 in the stable repo appears to be a beta 'not intended for production use'

Attached to Project: Arch Linux
Opened by cfr (cfr42) - Sunday, 10 September 2017, 03:33 GMT
Last edited by Antonio Rojas (arojas) - Sunday, 10 September 2017, 08:46 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Antonio Rojas (arojas)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Beta software marked as unsuitable for production use upstream has replaced stable software without any warning in the stable repo. Please note that I am not reporting the bugs in Kile. Those are not Arch's responsibility. I am reporting a bug in the packaging of unstable software as stable in the Arch repo. That is Arch's responsibility.

The Kile package was recently updated in the stable repo to 2.9.91-1. However, the splash screen tags it as version 3 beta. (And it surely behaves like beta software - it is not at all stable.)

2.9.91 is, in fact, the unstable beta released for testing on 3rd September. The News page on sourceforge (https://kile.sourceforge.io/news.php) says

> 2017-09-03 Kile 3.0 beta 1 release

> As of today you can download the first beta release for the Kile 3.0 series, which is, of course, only intended for testing and not for production use.

Moreover, the release page (https://kile.sourceforge.io/download.php) clearly shows

> 3.0 beta1 Source Code kile-2.9.91.tar.bz2


Additional info:

* Kile 2.9.91-1 (v3 beta)


Steps to reproduce:

* pacman -Syu with Kile installed

Expected results:

* Software in the stable repo should be stable and suitable for production use. At the least, upstream should claim it is suitable.

Actual results:

* Software is updated to an unstable version suitable only for testing and marked as such upstream.

If this was unavoidable e.g. because Arch no longer supports the framework required by the stable version of Kile, I would expect a warning prior to the upgrade being installed, letting me know the situation. That way, I could have chosen to postpone upgrading my system to a rather more convenient moment. Moreover, if I know I'm interacting with beta software, I typically proceed somewhat differently than if I believe I'm interacting with stable software. In particular, I would have been much more likely to quit in order to save my configuration, rather than continuing to work and losing all my changes when it crashed.

I've had at least two, but I think three or four, freezes, and one crash in two days. The thing has wiped my settings not once to upgrade, but twice. (It forgot it had already upgraded.) It has the memory of a goldfish: set a short-cut one moment; gone the next. Changing the font wipes all keyboard short-cuts configured. Opening a file from the command line fails.

These are upstream bugs, but the fact that beta software marked 'not for production' is packaged as stable is not an upstream bug. It is a packaging bug and, hence, Arch's responsibility.
This task depends upon

Closed by  Antonio Rojas (arojas)
Sunday, 10 September 2017, 08:46 GMT
Reason for closing:  Not a bug
Comment by Antonio Rojas (arojas) - Sunday, 10 September 2017, 08:45 GMT
This is intentional. The stable version of kile relied on some KDE4 libraries which have been unmaintained for 3 years. It also had some broken features due to some dependencies not being available anymore (eg.  FS#53419 ).

The kile release pace is extremely slow, which make it always lag behind its dependencies. That's why we've historically followed beta releases: https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/kile

The loss of your settings has nothing to do with it being a beta version, it's because it has been ported from KDE4 libraries to KF5, which save settings in a different path. You can recover them by copying ~/.kde4/config/kilerc and ~/.kde4/local/share/kile to ~/.config and ~/.local/share respectively.

Please report any specific issues you have with the new version, preferably upstream, and attaching backtraces in case of crashes or freezes. FWIW, I've been using this version for months without any issue. If you prefer to keep the old version, you can always install it from archive.archlinux.org and pin the version in pacman.conf, or add a kile-kde4 package to AUR.

Loading...