Re: Zsh on Debian is beginning to rot

[Axel Beckert <abe@xxxxxxxxxxxxxxx>]

Hi, 

I'll answer this one as a last one, as it's mostly off-topic here.
(And I'm admittedly slightly sick of having this discussion here.)

Unfortunately I forgot to give proper pointers to where such questions
are directed better, so I'll do it now at the very beginning of this
mail:

* Questions about Debian's zsh package should be sent to Debian Zsh
  Packaging Team: pkg-zsh-devel@xxxxxxxxxxxxxxxxxxxxxxx

* Questions (and answers) about how Debian works in general can be
  found in the FAQ: http://www.debian.org/doc/manuals/debian-faq/

* If you feel like you need to send you question to someone by e-mail,
  consider mailing lists such as debian-user@xxxxxxxxxxxxxxxx (for
  usage and general questions) or debian-mentors@xxxxxxxxxxxxxxxx (for
  packaging questions).

Now to Ray's questions...

On Mon, Sep 10, 2012 at 07:59:36AM -0700, Ray Andrews wrote:
> Why are Debian packages often so far behind?--vs, say, Arch, who often
> have packages out the day after they are released from upstream?

In General:
http://www.debian.org/doc/manuals/debian-faq/ch-choosing.en.html#s3.1.3

> This is not a bitchy comment, it is an honest question--I'm sure
> there is a very good reason, I'd just like to know what it is.

The goal is to create a rock-solid and hence well tested release. No
release dates known in advance, it's ready when it's ready.

There are three full distributions in Debian: stable, testing and
unstable. (For better overview I ignore oldstable and experimental.)

Stable is the currently released version of Debian. Testing is the
next to-be-released version and Unstable is where the development
happens, can be seen as some kind of rolling release. Packages without
release-critical bugs and whose dependencies are all in Testing
automatically propagate from Unstable to Testing after 10 days.

At some point the the release-team decides that Testing should be
frozen. This is basically what is know as feature freeze in software
development. From now on only packages which solely contain bugfixes
may enter Testing and the automatic propagation is disabled. Package
developers usually focus their work on bugfixing, package uploads with
new upstream versions are usually either delayed or uploaded to the
Experimental repo which can be seen as add-on to Unstable and may
contain quite buggy versions.

That's the state in which we're currently, by the way.

The release happens usually if the number of release-critical is very
close to zero. (And this means that buggy software may be kicked out
of Testing shortly before the release.) This freeze period usually
takes several months and is the reason for two things Debian is known
for: Already aged software at release time, but also being rock-solid
and the base for many derivatives.

> What is involved in making a package? I'd have thought that when
> someone releases something, it would take five minutes to just 'wrap
> it up' into the package format and that would be that.

Five Minutes is maybe to lower limit if you already have a lot of
practise and it's a very easy easy package with a common build system.
It may also take many hours if the build system is not a common one or
not used in the expected way by the upstream developers or the package
is complex in some other dimension (like building client and server of
some network protocol suites which should be packaged separately).

But maintaining a package involves more:

* Bug triage and forwarding bug reports to the upstream developers
  where applicable
* Bug fixing (in case it's a bug in packaging or upstream doesn't
  provide a fix)
* Sending bug fixes and patches to upstream.
* Care about smooth transitions from the version in the previous
  stable release of Debian to the next one in case there where bigger
  changes in the software.
* Finetuning for transitions of libraries used by the software (e.g.
  libjpeg6 to libjpeg8 or such)
* Writing documentation in case there is none provided by the upstream
  developers. (E.g. in Debian every command should have a man-page.)
* Provide default configurations suitable for the distribution.
* Make the build-system work on the completely automatic
  build-daemons. Not all build-systems work properly if the don't have
  a terminal or can ask questions.
* Determine the correct build-dependencies.

... and likely more things I just forgot now.

> When I download something as SRC and build it, it often seems
> 'that simple', yet packaging things seems to be quite a chore and
> to take years.

Well, if you package software for a general purpose distribution like
Debian, it has to work on many architectures and many different setups
(servers, desktops, embedded systems, with screen and without screen,
etc.), not only on your machine -- that sometimes gives quite some
headaches.

> Take Xfce. I'd like to try 4.10. Now, I know I can build it from
> SRC, but why is it that (at least last time I checked) it is not
> available in Testing?

The big desktop environments are usually software which has a lot of
reverse dependencies. Changing them shortly before a freeze usually
causes a lot of issues with packages which build-depend on them. Hence
such transitions are avoided already before the official freeze.

Other such packages which the maintainers usually freeze internally
before the distribution-wide freeze are quite central ones like the
installer, kernel, libc, boot loaders, etc.

> Arch had a package of it out, literally a couple of days after it
> was released.

Debian, too:

[2012-04-08] Accepted 4.10~pre1 in experimental (low) (Yves-Alexis Perez)
[2012-04-15] Accepted 4.10~pre2 in experimental (low) (Yves-Alexis Perez)
[2012-05-05] Accepted 4.10.0 in experimental (low) (Lionel Le Folgoc)

But in experimental for the reasons given above.

> I get the feeling that somehow software packages need to be
> customized and tweaked for a year or two before they can be
> included.

If you think of stable releases, yes, because they happen about every
two years and you have to add maybe half a year of freeze time.

After Debian released an new Stable release, with very few exceptions
where upstream is incapable of providing patches for security issues
(Oracle MySQL, WordPress, ...), no new features or new upstream
versions are added, just security and other release-critical bug-fixes
find their way into a stable release. See the FAQ mentioned above.

So if you consider a software which has entered Debian Unstable
shortly after a freeze, it likely takes 2 to 2.5 years until it is
part of a Stable release.

> Why? [Slackware, Arch]

Can't tell you what they do differently, because I never used them. I
know from Slackware that there dependency system is way simpler than
Debian's.

One thing which I know that many other distributions don't do as
heavily as Debian is to generate more than one binary package out of
one source package if parts of a project can be used standalone (or as
library for other programs), separately or are just not needed in
every installation. Many other Linux just build one package in such
cases which contains all the stuff. Debian's zsh source package
generates for example five binary packages: zsh, zsh-dbg (debugging
symbols), zsh-dev (zsh development headers), zsh-doc (documentation),
and zsh-static (static build).

Arch OTOH is a rolling release distribution. You have to compare that
rather to Debian Unstable at times when there's no freeze, and not to
Debian Stable. And I'd expect that you way find less differences,
especially not the ones you mentioned.

> Or take the current thing, Debian/zsh. It sounds like Axel has put
> his heart and soul into Debian/zsh,

Not only me, but all of our team. But remember that most of us
maintain more packages in Debian than just zsh.

Since we (the Debian zsh packaging team) also have one team member
which has zsh commit rights, Debian's zsh has nearly no patches
against upstream's code (only some Debian-specific stuff) because
usually all fixes and patches from us directly go into upstream's
code.

Other packages contain more patches, ranging from Debian-specific
things over bug-fixes not accepted upstream to features only present
in Debian.

> but what on Earth does that involve?

Look either in the changelog[1] or the git repository[2]

  [1] http://packages.debian.org/changelogs/pool/main/z/zsh/current/changelog
  [2] http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git

One thing which for example took quite a few commits and uploads to
get it right, is the regenerating of the documentation at build time.
zsh is distributed with precompiled docs in the tar ball. That's nice
for those who just untar the upstream tar ball, but those docs have
generic paths in there, which don't apply to Debian's file hierachy
(at least not in all cases). Hence we rebuild all docs with yodl at
build time.

Ubuntu in contrary has zsh in their main repo which means that it is
officially supported by Canonical while yodl is just part of the
community supported universe repo. So they ship the pregrenerated
upstream docs with partially wrong paths, because they don't want to
have to support yodl by Canonical, too.

> If anyone can help me to get a ground level understanding of this
> whole subject I'd be very obliged.

Hope this helped a little bit despite it became longer than expected
as the topic is all but trivial. I hope the remainder of the zsh-users
don't mind too much.

		Kind regards, Axel
-- 
/~\  Plain Text Ribbon Campaign                   | Axel Beckert
\ /  Say No to HTML in E-Mail and News            | abe@xxxxxxxxxxxxxxx  (Mail)
 X   See http://www.asciiribbon.org/              | abe@xxxxxxxxx (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)