On Thu, 16 Jan 2014, Sergey Popov wrote:
3. Also, another interesting question has come up in this thread, that of
non-binary packages. Should we give maintainers the option of
stabilizing them on all arch's themselves?
3. If code is interpreted rather then compiled, it does not matter that
it is properly ported on minor arches. I knew dozens of examples with
Perl and Python packages(not sure about Ruby, but Hans said that it
happens with it too). So, i would not treat such packages differently.
OK, let's be conservative. Python and Perl scripts may break on some
arches (I'd say it's a rare exception, perhaps 1%, but still). But what
about
dev-java/java-sdk-docs
dev-db/postgresql-docs
sys-kernel/linux-docs
dev-dotnet/gtk-sharp-docs
app-xemacs/general-docs
dev-util/kdevelop-php-docs
dev-util/gnome-devel-docs
app-vim/phpdocs
gnome-extra/gnome-user-docs
gnome-extra/gnome-getting-started-docs
dev-php/smarty-docs
dev-python/python-docs
dev-python/cheetah-docs
app-doc/php-docs
app-doc/root-docs
app-doc/geant-docs
app-doc/blas-docs
app-doc/lapack-docs
app-doc/gnucash-docs
app-office/abiword-docs
dev-lisp/hyperspec
sys-apps/man-pages[-*]
and maybe others? They contain no scripts which can possibly break. I'd
say they should be keyworded on all arches as soon as they are keyworded
on the first arch; the same goes for stabilization. I'd include also
packages containing only TeX/LaTeX code - TeX behaves identically on all
arches, this was and is its main strength. Also, probably,
python/perl/ruby interpreted scripts *which don't load extra libraries*
work identically on all arches not in 99% of cases but in 99.99% (0.01% is
for cases when the interpreter is broken on a given arch).
Andrey
