FS#54987 - [ejabberd] Symlink /usr/lib/ejabberd to the current /usr/lib/ejabberd-$pkgver

Attached to Project: Community Packages
Opened by Martin Schulze (schulmar) - Monday, 31 July 2017, 11:06 GMT
Last edited by Sergej Pupykin (sergej) - Tuesday, 01 August 2017, 09:13 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

With every update to ejabberd the path to the captcha.sh (/usr/lib/ejabberd-$pkgversion/priv/bin/captcha.sh) has to be changed in the configuration file, where it defaults to /usr/lib/ejabberd/priv/bin/captcha.sh. This is tedious and error prone and I think unnecessary:

For some time I have manually maintained a link /usr/lib/ejabberd -> ejabberd-$pkgversion but this is error prone as well.
Since version 17.07-1 (https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/ejabberd&id=7643c0ed8b1a5f4ad7f3a1915d9cbab0b7e2114b) this is not possible anymore, as there is now /usr/lib/ejabberd/priv/bin/epam.

I am not sure why this change was introduced but epam formerly lived in /usr/lib/ejabberd-$pkgversion/priv/bin/
so it should be possible to access it via /usr/lib/ejabberd/priv/bin/epam with the help of said symlink.

Are there any reasons not to provide this symlink in the package itself?
This task depends upon

Closed by  Sergej Pupykin (sergej)
Tuesday, 01 August 2017, 09:13 GMT
Reason for closing:  Fixed
Comment by Eli Schwartz (eschwartz) - Monday, 31 July 2017, 14:19 GMT
  • Field changed: Summary (Symlink /usr/lib/ejabberd to the current /usr/lib/ejabberd-$pkgversion → [ejabberd] Symlink /usr/lib/ejabberd to the current /usr/lib/ejabberd-$pkgver)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Architecture (x86_64 → All)
  • Field changed: Severity (Medium → Low)
  • Task assigned to Sergej Pupykin (sergej)
epam was moved as a result of  FS#53607 
Comment by Martin Schulze (schulmar) - Monday, 31 July 2017, 14:47 GMT
Okay, it looks like my request might solve that problem too.
May I ask why we even have the version in the lib path? It seems that upstream does not intend for that.
Comment by Eli Schwartz (eschwartz) - Monday, 31 July 2017, 14:51 GMT
Seems kind of odd to me too, but what do I know, I'm just the bug triager. :p
Comment by Martin Schulze (schulmar) - Monday, 31 July 2017, 15:01 GMT
@eschwartz: Quick question about the severity: The current state prevents the service from even starting up if you are using captchas, which are disabled by default. Yet I am only one user and had a quick workaround. How did you come to the conclusion of low severity?
Comment by Sergej Pupykin (sergej) - Monday, 31 July 2017, 15:01 GMT
"make install" command installs files into /usr/lib/ejabberd-17.07 so upstream uses version in paths.
Comment by Sergej Pupykin (sergej) - Monday, 31 July 2017, 15:15 GMT
I will link whole /usr/lib/ejabberd-$pkgver directory to /usr/lib/ejabberd
Comment by Eli Schwartz (eschwartz) - Monday, 31 July 2017, 16:33 GMT
@schulmar,

There's a link the the Reporting Bug Guidelines at the top of the bugtracker interface.
The Severity section discusses the differences in severity; for optional functionality that requires configuration updates on package upgrades, this is not so severe. Severity is not a matter of how quick the *workaround/fix* is, but of how much impact the *problem* has. :)
Quick workarounds/fixes are great -- it just means bugs can be resolved faster.
Comment by Sergej Pupykin (sergej) - Monday, 31 July 2017, 17:33 GMT
please try ejabberd-17.07-3
Comment by Martin Schulze (schulmar) - Tuesday, 01 August 2017, 04:55 GMT
That worked. Thanks for the fast response.

Loading...