Re: Why we should run away from n*100 packages per doc
----- Original Message -----
From: "Paul W. Frields" <stickster(a)gmail.com>
To: <fedora-docs-list(a)redhat.com>
Sent: Friday, June 05, 2009 8:17 AM
Subject: Why we should run away from n*100 packages per doc
http://lists.fedoraproject.org/pipermail/rel-eng/2009-June/005572.html
You can see the same discussion occurring on the rel-eng list
concerning the TeX Live 2008/9 packaging. Hopefully it will save
everyone needless frustration if we instead pursue getting the Zikula
CMS set up so any user can simply click his way to a specific RPM for
his document and language. Putting these in the Fedora repository is
simply begging for conflict.
IMO, a perfect solution would allow a user to install documentation that he
wants in his own language, or in the combination of languages he wants
installed. Given that there are over 1000 possible combinations of single
language/document/format, that would add a lot of packages to a PackageKit
that is already burdened with far too many packages to be useful (but that
is another issue).
A single RPM per document/language/format seems an ideal approach, but
clearly adding all those packages to the repositories is not a good answer.
Doing something with Zikula does seem like a possible solution. All those
RPMs wouldn't seem so daunting if you chould choose your format, languge and
document independently.
Along with that CMS we should be planning for how to *make sure
users
find that site.*
As well as docs.fp.o. I suspect a lot of the time a user would just as soon
read the documentation online if he knew how to find it. Seems like we need
an online and an install choice, or perhaps that is at the bottom; after
choosing document/language/format the user has the choice of reading or
installing. Or, perhaps installing and reading are different thought
processes, and the choice is at the top (which give us more to maintain,
tho).
Maybe what we do is add an install choice in docs.fp.o (or more likely it's
successor), and a menu choice to view documentation. All sorts of potential
variants with good and bad of each. Those that seem the most user friendly
also seem like the most work!
--McD