[arch-general] Upstream urls and package descriptions

[Karol Blazewicz]

Intro:
Below are some questions / ideas I came up with. I simply don't know
if anyone cares about these issues, whether there are rules or at
least suggestions how to best deal with them or is it up to the
maintainer.

I've heard there were some plans wrt a build server that would
periodically check if packages still build. Any news?
If there indeed are issues that need fixing, should I file the
low-priority bugs now? Summer vacation may not be the best time for
Arch-related work so maybe I should wait until September so that
people are back from holidays?



Upstream urls:
I found that dozens of packages in the repos have an upstream url that
prints 'Page Not Found' in one way or another. Should I open bug
reports for these packages or does nobody care about it? I could also
check if the source is still available. If opening bug reports is OK,
should I limit creating the reports to e.g. 10 a day?
If I find a url that works, I will include it as a suggestion for the
maintainer.

For example for
https://www.archlinux.org/packages/community/i686/autocutsel/ neither
the url nor the source is available, but I found what seems like a
perfectly good autocutsel website: http://www.nongnu.org/autocutsel/
with a link to the source.

Some projects seem to be gone for good e.g.
https://www.archlinux.org/packages/extra/i686/apricots/ even grabs the
sources from ftp.archlinux.org
https://projects.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=packages/apricots
Would http://freecode.com/projects/apricots be a better website? It
has some info e.g. that last development is from a decade ago, a
screenshot, a longer description ...

What about urls that point to a redirect? Is it OK only if the
redirect is automatic and otherwise upstream urls should be updated if
they moved e.g. from SourceForge to GoogleCode?
An example: https://www.archlinux.org/packages/extra/any/junit/ has
http://junit.sourceforge.net/ as the upstream url, but when you go
there, it says 'Please see our main site at junit.org'.


Is there a rule that 'www' should be omitted or that it should be included?
https://www.archlinux.org/packages/extra/i686/alsa-lib/ :
http://www.alsa-project.org
https://www.archlinux.org/packages/extra/any/alsa-firmware/ :
http://alsa-project.org/

What about the slash at the end of the url?
Sometimes the slash makes a difference:
https://www.archlinux.org/packages/community/i686/pidgin-toobars/ uses
http://vayurik.ru/wordpress/en/toobars/ and shows (via a redirect) the
Russian version http://vayurik.ru/wordpress/toobars while the English
version demands no slash at the end of the url:
http://vayurik.ru/wordpress/en/toobars

The same upstream url can be used by many packages and standardizing
would make it a bit easier to find which packages need to have the
upstream url updated.


Are upstream urls mandatory?
https://www.archlinux.org/packages/extra/any/hwdetect/ does not have
one.



Package descriptions:
There was an attempt at improving the descriptions last year, but it
didn't go so well
https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/bitcoin&id=bd4647fb433c517c03fb08f869944dc987372a69


I don't know if maintainers should write package descriptions or
should they just take them from upstream, but IMHO e.g.
https://www.archlinux.org/packages/extra/i686/kdeplasma-addons-wallpapers-virus/
: 'Description:    Virus'
has to go.

Even
https://www.archlinux.org/packages/extra/i686/kdeplasma-addons-wallpapers-weather/
- Weather
or
https://www.archlinux.org/packages/extra/i686/kdetoys-ktux/ - KTux
are pretty bad descriptions.

Quite a few descriptions could be more informative, but I don't know
if anyone cares about it e.g. description for
https://www.archlinux.org/packages/extra/i686/kdeutils-ktimer/ says
'Countdown Launcher' and is IMHO too terse. Should I suggest changing
it upstream, will the maintainer change it to a more descriptive one
or is it considered just pointless churn?

Similarly, https://www.archlinux.org/packages/extra/i686/kdeplasma-addons-applets-calculator/
could be described as e.g. 'A simple calculator' instead of the
current 'Calculate simple sums'.


Is adding 'data files' phrase to descriptions of packages that provide
architecture-independent data recommended?


I've noticed many packages share the same description, usually because
it's a generic one:
monica - A monitor calibration tool
kdegraphics-kgamma - A monitor calibration tool

or because the packages represent different version of e.g. the same toolkit:
qt3 - A cross-platform application and UI framework
qt4 - A cross-platform application and UI framework

Sometimes the descriptions explicitly says it's a python2 thing:
python2-atspi - Python 2 bindings for at-spi
python2-dbus - Python 2.7 bindings for DBUS

Some language-related packages use the same description for all of them e.g.
xpdf-korean - Encoding information to use specific character sets in
Xpdf; does not include fonts
vim-spell-af - Language files for Vim spell checking

Other packages, like firefox-i18n-* or libreoffice-* adjusted the
description for each package:
firefox-i18n-af - Afrikaans language pack for Firefox
libreoffice-af - Afrikaans language pack for LibreOffice

Is one way preferred over the other or is it up to the maintainer?
Should language files always have a description that says which
language do they represent or are package names enough?


I also found
https://www.archlinux.org/packages/extra/any/libreoffice-sid/ - ???
language pack for LibreOffice
https://www.archlinux.org/packages/extra/any/libreoffice-tt/ - TT ?
language pack for LibreOffice

What's this?