[Pkg-bitcoin-devel] backports enabled by default in jessie

[Scott Howard]

Hello bitcoin team, please see the discussion on debian-devel that is
very related to many of the discussion on this list. The start of the
thread is included below, and is archived here:
https://lists.debian.org/debian-devel/2014/11/msg00406.html

In short, backports may be enabled by default in Jessie. That means
that we can, in theory, deliberately block packages from being in
Jessie, maintain them in jessie-backports so they are always
up-to-date. This is especially important for mining software (to
support new hardware) and bitcoin clients that need the most
up-to-date versions (armory and bitcoind/bitcoin-qt).

Please follow that discussion if you are interested. I think the
bitcoin package is in a good position either way, armory should follow
closely to see what the consensus is, and the mining software
(bfgminer/cgminer) should also watch closely. I think minepeon is in
the process of being packaged, that too will be affected by this.

If we decide to maintain bitcoin packages is such a way, we probably
will need to document this carefully and make sure the team is ready
for continued maintenance of all packages, possibly recruit some more
people to help out as well as look for other packages that would be
good to maintain under the same umbrella. It would also be possible to
create a "cryptocurrency OS" that is a debian pure blend [1], if
someone was so inclined, that would perpetually be up-to-date and
cover the whole cryptocurrency ecosystem.

Regards,
Scott

[1] https://wiki.debian.org/DebianPureBlends

On Tue, Nov 11, 2014 at 8:30 AM, Rebecca N. Palmer
<rebecca_palmer at zoho.com> wrote:
> It has been recently stated [0-1] that backports is enabled by default in
> Jessie.
>
> 1. Does that mean that if pkgX is in jessie-backports but not jessie,
> "apt-get install pkgX" will install it from -backports?
>
> 2. If so, when (if ever) is it appropriate to deliberately invoke that
> behaviour by removing pkgX from jessie?
> Possible candidates:
> a. Packages that work closely with hardware, where old versions don't work
> with new hardware (example: beignet)
> b. Packages that implement fast-evolving file formats or network protocols,
> where you need the same version as the people you are communicating with
> (possible example: jscommunicator [2])
> c. Packages that are generally rapidly improving, and are typically used
> where this improvement is more important than stability
>
> The advantage of doing so (over having both the old version in jessie and
> the new one in jessie-backports) is that non-technical users (who may not
> know that backports exists) get the new version they probably want; the
> disadvantage is that users who explicitly want stability can no longer
> choose it (except by pinning or using snapshot.debian.org, which also block
> security updates of that package).
>
> In the long run it may be a better idea to have these packages suggest
> upgrading to -backports in their "this hardware/protocol version/option not
> supported" error message, or on startup if there is no easy way to identify
> attempts to use the newer features, but it is too late to do this for
> jessie.
>
> (Release team have already ruled that a. (#767961) and b. (#768933) are not
> valid reasons for freeze exceptions; I guess this would also forbid stable
> updates)
>
> [0] https://lists.debian.org/debian-devel/2014/11/msg00339.html
> [1] My own sources.list has
> # jessie-backports, previously on backports.debian.org
> # Line commented out by installer because it failed to verify:
> #deb http://ftp.uk.debian.org/debian/ jessie-backports main
> but https://lists.debian.org/debian-user/2014/09/msg01174.html reports
> getting one with that line uncommented
> [2] https://lists.debian.org/debian-release/2014/11/msg00866.html
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-REQUEST at lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster at lists.debian.org
> Archive: https://lists.debian.org/54620F78.4040501@zoho.com
>