[Pkg-crosswire-devel] Backports inclusion
jmarsden at fastmail.fm
Mon Jun 1 06:46:33 BST 2009
Dmitrijs Ledkovs wrote:
> Except if our packages don't work. People then go on and enable
> backports and then their system get's even more unstable.
Well, OK, although I've not seen much evidence of system instability
arising from enabling backports (I tend to enable that on my Ubuntu
systems!), maybe others have.
> No problem there except that the change affects all future builds of
> all packages.
That's too broad a statement, I think? The change *might* affect future
builds, *if* *-backports contains updated copies of libraries we need
that we do not have Depends: info for already in our control file.
Until *-backports really *does* do that, we're safe :)
>> deb http://archive.ubuntu.com/ubuntu/ jaunty-backports main universe
> Well enabling jaunty backports on hardy machine would result in some
> funky stuff happening ;-)
Good catch :) BTW, maybe
is a better place to point users to for docs on adding backports?
>> Is there actually an *harm* for non-hardy users ...
> So no, I don't know of current packages that might bring harm of not
> having backports enabled on Intrepid & Jaunty while using backports at
OK. So, as far as we know, we're good for the moment. We could test
this by making two pbuilders, one with backports enabled and one without
and trying builds of our packages and then comparing the results, if we
want to test this in depth.
Longer term, once we get our stuff into Karmic (and Karmic is released!)
we can then also get our stuff into *-backports or *-updates (whichever
one is easier to get packages into, I always forget which way around
they are!) and so avoid normal users needing to use a PPA at all. The
longer term goal is to get all these packages into Ubuntu repositories,
not keep on requiring that end users have to enable our PPA. PPAs are
for personal (or team) use, not really intended for global end user
> I don't know of such, but backport's wiki suggest that it is a possibility.
Agreed. This is something to check for. Especially if we end up
continuing to recommend the PPA to end users -- but that's not really
what we want to be doing anyway.
> For the sake of having one PPA for users I have a two new different proposals:
> 1) Copy the hardy-backport Qt into our ppa (might be just a little
> suspicious for users.......)
I thought about doing that, and I even downloaded the sources ready to
rebuild it with a ~hardy version suffix or whatever, so it is
"different" enough from the official package.
But technically, we are not supposed to do straight rebuilds of
unmodified Ubuntu packages in PPAs. The PPA FAQ says "We will not
accept uploads of packages that are unmodified from their original
source in Ubuntu or Debian, only packages that include your own
changes." -- and just adding a ~hardy suffix to the version number isn't
really in the spirit of this rule :)
> 2) Enable back ports only while building bibletime on hardy and keep
> it turned off for the rest of the time.
That's an interesting idea. It might be awkward to remember to do, but
it could work.
IMO, we only need to do either of these if we suspect we're going to hit
a problem leaving backports enabled in the PPA. And so far, we're not
seeing any such problem.
There are a couple of post 2.0 minor bugfix patches for BT already, so
I'm likely to include those in our BT 2.0 packages. Once that is done,
and we (I) provide a BT 2.0 package for Roberto to upload to unstable,
we could turn off backports in the main ~pkgcrosswire PPA, if leaving it
enabled really worries you. But I think you are worrying unnecessarily
about a hypothetical issue here.
How did the exams go?
More information about the Pkg-crosswire-devel