[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: third-party packages adding apt sources

On Sat, May 21, 2016 at 02:07:53PM +0800, Paul Wise wrote:
> On Fri, May 20, 2016 at 1:34 PM, Vincent Bernat wrote:
> > Totally agree. Our standards are far too high for many upstreams.
> I don't understand the disconnect here. Are upstreams not interested
> in software quality to the extent we are?

I don't think it's that upstreams aren't interested in quality, but
that Debian and (some) upstreams have different opinions on what
aspects of quality are more important.

* Debian: don't embed copies of libraries you use. It makes it harder
  to do security updates in the libraries, makes it harder to use the
  libraries on their own, and makes the Debian package archive
  unnecessarily larger.

  Some upstreams: we embed copies of libraries. It makes it easier to
  install our software, and guarantees us that the library doesn't
  change from underneath us, and that means we don't need to support
  many versions of the library. We're an active project, and if a
  library needs a security update, we do it quickly.

* Debian: it's important to follow Debian Policy and the Debian
  workflow of uploading to unstable and letting packages flow from
  there to testing and stable, if they don't have bad bugs. There's
  thousands of people making packages and things will break if they
  all do the same thing differently.

  Some upstreams: it's OK to cut some corners and do things simply. We
  care about getting the software into the hands of its users as soon
  as possible, and we also don't have a lot of time to spend on
  packaging. From our point of view, packaging is a necessary evil
  that is much too difficult and takes much too much time from us.
  That's effort we could spend on making the software better instead.

* Debian: it's important to have package versions that can be
  supported for many years. We produce a release every two years, and
  support it for at least three, and more if one counts the LTS
  project. Software that changes a lot, or that has an API that
  changes a lot, or that doesn't separate security updates and
  backport those to the version included in a Debian release, make
  this harder for us. We can't generally update to a new upstream
  release whenever there is a security problem, as it would negate the
  point of making Debian releases. For example, the new upstream
  version might require entirely new forests of dependencies, or newer
  versions of dependencies, all the way down to the kernel. For some
  packages that we deem sufficiently important to our users, we deal
  with that, but it is not something that generalises to all packages.

  Some upstreams: we don't support our old releases. We have only so
  much time to spend on this software, and supporting old releases
  would take a lot of effort we don't have time for. That's why we
  embed most of our dependencies into the installation packages we
  make, so that they can be installed onto the Debian releases, even
  if we decide to require more dependencies, or newer versions of

Et cetera. Debian has one set of quality factors it particularly cares
about, and some upstreams think differently.

Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh

Attachment: signature.asc
Description: PGP signature

Reply to: