[Pkg-crosswire-devel] Backports inclusion
jmarsden at fastmail.fm
Tue Jul 28 02:59:43 BST 2009
Daniel Glassey wrote:
> Just my tuppence as an occasional hardy user. On an LTS distro there
> is _no way_ I'd advise people (or do it myself) to enable backports
> without a simple way to only enable it for certain packages. I'd be
> better off installing a newer Ubuntu release.
Of course! Most desktop users are going to be better off installing the
current release. But apparently, some users are being prevented from so
doing by rules set within their organization(s).
> I would say that the PPA is a good way to do the selective updates
> i.e. enable only specific backports.
That's not what PPAs are for. The first P in PPA stands for Personal.
I think users (and organizations) need to decide what they really want,
and understand the consequences of their own choices and actions :) If
a user/org *chooses* to restrict themselves to an LTS release, they
thereby *choose* to restrict themselves to software that compiles and
runs in that older OS environment. If they don't like that consequence
of their choice, then on a desktop machine (or a set of such desktop
machines), the logical response is to make a different choice -- to use
a newer OS release instead.
If that is completely politically impractical, then enabling backports
is IMO simple and very workable. Easier than telling normal end users
to use PPAs, and how to add certificates for those PPAs so packages from
them validate, etc.
Packages in -backports are, on average, more thoroughly tested than
stuff in random PPAs. So if stability and reliability is the concern,
PPAs are higher risk. We should not be encouraging end users (who value
stability so highly that they stick with an LTS release) to use PPAs!
> As it happens I already had qt4.4 from the kde4 ppa. I guess that was
> there before the backports version but I don't know.
Which neatly demonstrates the issues of self-managing your set of
package sources; it adds complexity, and unless you make rigorous notes,
over time you end up not being quite sure where you got stuff from and
why you got it... :) Adding one single Ubuntu-official new source of
packages (hardy-backports) is IMO much cleaner and much simpler than
adding several PPAs and their individual certificates.
>  I know there is apt pinning and it is what I'd do but I don't
> think it is reasonable to tell users to jump through that hoop.
So you are saying that downloading a single text file is far worse (far
more complex) than downloading and installing one certificate per PPA? Why?
> And there is telling the users to download the qt packages manually
> which would also be a right pain.
IMO we should support the existing official Ubuntu distribution network.
The goal was to get this software "into" Debian and Ubuntu. Within
Ubuntu, that means "into" universe, and for backports to older OS
releases, it means "into" -backports.
Anything else at all (for normal end users) is (IMO again) just added
complexity that they simply should never have to learn about. PPAs are
(a) personal and (b) somewhat anarchic and unregulated. They are not
intended or designed as a means for widespread end-user package
distribution. That is what the official repositories are for :)
If a large organization has real issues with this approach, and requests
an apt preferences file that pins things so only SWORD-related software
from -backports get used, OK, we can provide one for them.
Is whoever put the "thou shalt only use Hardy" rule into effect in their
organization(s) willing to discuss with us its rationale, as well as its
effects on their end users who now wish to use newer bible-related
software than exists in Hardy?
Final thought: For users with reasonably modern PCs, running a copy of
the latest and greatest Ubuntu in a virtual machine inside their LTS
release primary OS is now very practical. Best of both worlds??
More information about the Pkg-crosswire-devel