[Pkg-crosswire-devel] Backports inclusion

[Jonathan Marsden]

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[1]. 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.

> [1] 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??

Jonathan