Zsh on Debian is beginning to rot

Zsh on Debian is beginning to rot

[Mark van Dijk]

Hello everyone,

Take a look at this output of my Debian Squeeze box:

Package: zsh
Version: 4.3.10-14

Package: zsh-beta
Version: 4.3.10-dev-1+20100720-1

Package: zsh-dev
Version: 4.3.10-14

Package: zsh-static
Version: 4.3.10-14

Debian sid is not much better - version 4.3.17.

I wonder why it's been so long since Zsh has had a decent upgrade on
Debian. Is there no package maintainer? Is there a semi or non-official
Zsh repository for Debian?

Of course (imho) the most convenient solution would be if debian just
would replace all the zsh packages in stable, testing and unstable with
a single zsh package. Version 5.

Hopefully someone's reading this who is able to pull some strings...

-- 
Stay in touch,
Mark van Dijk.               ,---------------------------------
----------------------------'         Sun Sep 09 11:08 UTC 2012
Today is Boomtime, the 33rd day of Bureaucracy in the YOLD 3178

Re: Zsh on Debian is beginning to rot

[Frank Terbeck]

Mark van Dijk wrote:
> Debian sid is not much better - version 4.3.17.

What do you mean not much better. There is virtually no difference
between 4.3.17 and 5.0.0.

There is a 5.0.0 package in experimental. It's not in sid, because of
the current freeze in debian..

> I wonder why it's been so long since Zsh has had a decent upgrade on
> Debian. Is there no package maintainer? Is there a semi or non-official
> Zsh repository for Debian?

There is actually a team that looks after it. Visit #pkg-zsh on freenode
if you want to help.

> Of course (imho) the most convenient solution would be if debian just
> would replace all the zsh packages in stable, testing and unstable with
> a single zsh package. Version 5.
>
> Hopefully someone's reading this who is able to pull some strings...

There is no need to pull strings. 4.3.17-1 is in testing, so it will be
in the next stable release. And like I said, 4.3.17 and 5.0.0 is
practically the same code base. Don't think 5.0.0 is something different
because of the major release; you would be wrong.

Regards, Frank

Re: Zsh on Debian is beginning to rot

[Vincent Lefevre]

On 2012-09-09 13:48:20 +0200, Frank Terbeck wrote:
> What do you mean not much better. There is virtually no difference
> between 4.3.17 and 5.0.0.

Wrong. There's an important difference: bug 679345 (svn completions)
is fixed in zsh 5.0.0, but not in 4.3.17.

> There is a 5.0.0 package in experimental. It's not in sid, because of
> the current freeze in debian..

That's stupid. Subversion was moved to 1.7 in sid, but in sid, zsh
remains with svn completion rules that are incompatible with svn 1.7.
So, unless some zsh update is done (possibly only the completion rules),
this will be an important regression for users of zsh and svn in the
next stable version.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Zsh on Debian is beginning to rot

[Frank Terbeck]

Vincent Lefevre wrote:
> On 2012-09-09 13:48:20 +0200, Frank Terbeck wrote:
>> What do you mean not much better. There is virtually no difference
>> between 4.3.17 and 5.0.0.
>
> Wrong. There's an important difference: bug 679345 (svn completions)
> is fixed in zsh 5.0.0, but not in 4.3.17.

One bug in one small part of the shell as a whole does NOT invalidate my
statement. Not at all.

>> There is a 5.0.0 package in experimental. It's not in sid, because of
>> the current freeze in debian..
>
> [...] Subversion was moved to 1.7 in sid, but in sid, zsh
> remains with svn completion rules that are incompatible with svn 1.7.
> So, unless some zsh update is done (possibly only the completion rules),
> this will be an important regression for users of zsh and svn in the
> next stable version.

That is unfortunate (even though it does not break everything into an
unfixable state). However, that has not been made clear in the bug
report. It might be possible to get a 4.3.17 package into wheezy, that
updates just the _subversion completion. Talk to the maintenance team.

If that is not possible (which would surprise me, to say the least),
admins can always drop a fixed _subversion into
`/usr/local/share/zsh/site-functions'.

I realise, that the latter would not be a desirable state at all; so no
need to lecture me on that. I am just pointing out a way out in the
worst case scenario.

Regards, Frank

Re: Zsh on Debian is beginning to rot

[Vincent Lefevre]

On 2012-09-10 10:42:41 +0200, Frank Terbeck wrote:
> Vincent Lefevre wrote:
> > On 2012-09-09 13:48:20 +0200, Frank Terbeck wrote:
> >> What do you mean not much better. There is virtually no difference
> >> between 4.3.17 and 5.0.0.
> >
> > Wrong. There's an important difference: bug 679345 (svn completions)
> > is fixed in zsh 5.0.0, but not in 4.3.17.
> 
> One bug in one small part of the shell as a whole does NOT invalidate my
> statement. Not at all.

It may be a small part of the shell, but affects all users of both zsh
and svn, IMHO not a small part of the zsh user base (by "small", I mean
not small enough to ignore the bug). And this bug is very annoying in
practice.

> If that is not possible (which would surprise me, to say the least),
> admins can always drop a fixed _subversion into
> `/usr/local/share/zsh/site-functions'.
> 
> I realise, that the latter would not be a desirable state at all; so no
> need to lecture me on that. I am just pointing out a way out in the
> worst case scenario.

The main problem with that is that it is easy to forget such files,
thus the one that will be taken into account may never be updated,
and this is really bad.

It would have been great if such files were versioned, so that it
would be possible to tell zsh to take the most recent one.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Zsh on Debian is beginning to rot

[Michael Prokop]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

* Vincent Lefevre [Mon Sep 10, 2012 at 10:06:50AM +0200]:
> On 2012-09-09 13:48:20 +0200, Frank Terbeck wrote:

> > There is a 5.0.0 package in experimental. It's not in sid, because of
> > the current freeze in debian..

> That's stupid. Subversion was moved to 1.7 in sid, but in sid, zsh
> remains with svn completion rules that are incompatible with svn 1.7.
> So, unless some zsh update is done (possibly only the completion rules),
> this will be an important regression for users of zsh and svn in the
> next stable version.

In wheezy there currently is subversion 1.6.17dfsg-4, so I don't see
your point in calling "That's stupid".

*If* subversion 1.7 is targeted for wheezy (pointers to release
exceptions please) then we will try to care of the svn completion.

regards,
-mika-

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Zsh on Debian is beginning to rot

[Vincent Lefevre]

On 2012-09-10 10:56:38 +0200, Michael Prokop wrote:
> * Vincent Lefevre [Mon Sep 10, 2012 at 10:06:50AM +0200]:
> > On 2012-09-09 13:48:20 +0200, Frank Terbeck wrote:
> 
> > > There is a 5.0.0 package in experimental. It's not in sid, because of
> > > the current freeze in debian..
> 
> > That's stupid. Subversion was moved to 1.7 in sid, but in sid, zsh
> > remains with svn completion rules that are incompatible with svn 1.7.
> > So, unless some zsh update is done (possibly only the completion rules),
> > this will be an important regression for users of zsh and svn in the
> > next stable version.
> 
> In wheezy there currently is subversion 1.6.17dfsg-4,

Ah, OK, but...

> so I don't see your point in calling "That's stupid".

> *If* subversion 1.7 is targeted for wheezy (pointers to release
> exceptions please) then we will try to care of the svn completion.

Well, unstable (sid) is still affected, and I don't see why different
rules should be applied to subversion and zsh. There are 2 cases:

1. The freeze just prevents unstable packages from entering testing,
   in which case it would be OK to make zsh 5.0.0 enter unstable (sid)
   and the sentence "It's not in sid, because of the current freeze in
   debian." is wrong, or at least very inaccurate.

2. The freeze prevents unstable updates, with the goal to move current
   unstable packages to testing, in which case it would be better to
   take care of the svn completion now (that would fix the bug in
   unstable now and would allow more tests by Debian/unstable users,
   while still not affecting testing immediately).

The idea is to keep zsh synchronized with Subversion incompatible
changes at every level.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Zsh on Debian is beginning to rot

[Axel Beckert]

Hi Vincent,

On Mon, Sep 10, 2012 at 01:59:32PM +0200, Vincent Lefevre wrote:
> On 2012-09-10 10:56:38 +0200, Michael Prokop wrote:
> > *If* subversion 1.7 is targeted for wheezy (pointers to release
> > exceptions please)

There is no freeze exception for Subversion. But the opposite exists:
[1] says: "Not touching package due to block request" -- so the Debian
Release Team explicitly prevents Subversion 1.7 to migrate to Testing
currently. I don't expect this to change.

  [1] http://qa.debian.org/excuses.php?package=subversion

> > then we will try to care of the svn completion.
> 
> Well, unstable (sid) is still affected, and I don't see why different
> rules should be applied to subversion and zsh.

During the freeze it is preferred that updates to Testing happen via
an upload to unstable. So if we upload 5.0.0 to Unstable, we hurt
ourselves if he have to fix an important bug in 4.3.17 from testing
afterwards. The same may count for uploading a 4.3.17 with a fix for
Subversion 1.7 (but would be easier to revert).

There is a side-channel for such cases via an upload
testing-proposed-updates, but according to the freeze policy[2] for
Debian Wheezy this is only an option for release-critical bugs (i.e.
those of the severities "serious", "grave" or "critical"), but not for
bugs which just have the severity "important".

  [2] http://release.debian.org/wheezy/freeze_policy.html

That's why during the freeze for a new stable release we and most
other Debian maintainers upload new upstream versions or stuff only
relevant for Unstable just to Experimental and not to Unstable.

(And yes, Subversion updates for Testing are only possible via
testing-proposed-updates. But that's not our team's problem.)

If you think that's the wrong approach please have a look at [3]
(keywords CUT and Rolling) and help to make that idea becoming
reality.

  [3] https://lists.debian.org/debian-devel/2011/06/msg00136.html

> 1. The freeze just prevents unstable packages from entering testing,
>    in which case it would be OK to make zsh 5.0.0 enter unstable (sid)

If you want that fixed in your Unstable installation, add the
Experimental repository and install zsh from there.

> The idea is to keep zsh synchronized with Subversion incompatible
> changes at every level.

No, the idea is to make the next Debian stable release as stable as
possible and therefore to not put any tripping hazard in its way.
Everything else is subject to Debian Experimental until the freeze is
over.

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

Re: Zsh on Debian is beginning to rot

[Axel Beckert]

Hi,

On Sun, Sep 09, 2012 at 01:10:50PM +0200, Mark van Dijk wrote:
> Subject: Zsh on Debian is beginning to rot

Ehm, do you really know what you're talking about?

> Take a look at this output of my Debian Squeeze box:
> 
> Package: zsh
> Version: 4.3.10-14

Squeeze is about 1.5 years old, Squeeze's feature freeze was in the
beginning of August 2010 and zsh 4.3.10 was the uptodate zsh
developement (!) release back then.

Do you really know how Linux distributions in general and Debian in
specific works? I don't think so.

> Package: zsh-beta
> Version: 4.3.10-dev-1+20100720-1

Compare the freeze date with the date in the version number: Clint
upload an uptodate snapshot just two weeks before the freeze for
Squeeze.

> Debian sid is not much better - version 4.3.17.

Which is the second last release of zsh and the last developement
release of zsh before the freeze for Wheezy. Nothing wrong here
either.

As Frank already pointed out, there is an uptodate 5.0.0 package
(actually in its second incarnation) in Debian Experimental. It's in
Experimental and not Sid because of the freeze for Wheezy. Please read
http://www.debian.org/devel/testing if you don't understand why it
works that way and not differently.

> I wonder why it's been so long since Zsh has had a decent upgrade on
> Debian.

Because it will never happen after a stable release has happened and
it usually doesn't happen after a feature freeze either. That's why
it's called "feature freeze" and "stable". No more changes which could
break something. Stable APIs and ABIs. That's what users can rely on.

> Is there no package maintainer?

There is actually a team of four maintainers plus several very active
and helpful regular bug reports -- which btw. all read this mailing
list, too. All in all a very healthy maintainer infrastructure of
which many packages can only dream of.

> Is there a semi or non-official Zsh repository for Debian?

We see no need for that. You can use the Debian Experimental
repository if you want to stay on bleeding edge stuff during the
freeze for the next Debian stable release.

There is though the Jenkins repository[1] of the Debian Zsh Packaging
Team which automatically builds packages after each push from a team
member. Those packages are really bleeding edge, but be aware that
those packages may be broken, too. Use at your risk and don't whine if
it breaks your box. (Bug reports welcome, though. ;-)

> Of course (imho) the most convenient solution would be if debian
> just would replace all the zsh packages in stable, testing and
> unstable with a single zsh package. Version 5.

Ok, this shows that you really have _NO_ idea how Debian or most other
Linux distributions work. Go and do your homework before complaining.
See the according question[2] in FAQ for a start. (Or use a rolling
release based Linux distribution instead in case you dislike the idea
of _stable_ _releases_.)

> Hopefully someone's reading this who is able to pull some strings...

Yeah, the strings we pulled are those in our e-mail client so that 
two e-mails to the zsh users mailing list were written.

Footnotes:

  [1] http://jenkins.grml.org/job/zsh-source/
  [2] http://www.debian.org/doc/manuals/debian-faq/ch-getting.en.html#s-updatestable

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

Re: Zsh on Debian is beginning to rot

[Mark van Dijk]

Hello,
> On Sun, Sep 09, 2012 at 01:10:50PM +0200, Mark van Dijk wrote:
> > Subject: Zsh on Debian is beginning to rot
> 
> Ehm, do you really know what you're talking about?
> 
> > Take a look at this output of my Debian Squeeze box:
> > 
> > Package: zsh
> > Version: 4.3.10-14
> 
> Squeeze is about 1.5 years old, Squeeze's feature freeze was in the
> beginning of August 2010 and zsh 4.3.10 was the uptodate zsh
> developement (!) release back then.

Yeah, so it's 2 years old and it did have some minor fixes since then.
The word 'rot' was chosen poorly sorry about that, if I pissed you
off too much I apologise.

> Do you really know how Linux distributions in general and Debian in
> specific works? I don't think so.

No I have absolutely no clue. I just started working with it yesterday
after I spilled an entire can of Dr. Pepper on my MSX2. It really
saddened me because I almost got to the end of Road Fighter.

Ok, here's the honest answer. While I indeed do realise how Debian
works with their versioning strategy (and I commend them for that in
general) there is a genuine (but admittedly stupid) reason for why I
sent my email --

> > Package: zsh-beta
> > Version: 4.3.10-dev-1+20100720-1
> 
> Compare the freeze date with the date in the version number: Clint
> upload an uptodate snapshot just two weeks before the freeze for
> Squeeze.
> 
> > Debian sid is not much better - version 4.3.17.
> 
> Which is the second last release of zsh and the last developement
> release of zsh before the freeze for Wheezy. Nothing wrong here
> either.

-- i.e. I did not check the versioning of Zsh properly. For some reason
the wrong version stuck with me (4.7.13) which is bogative. This
morning I got a bit too annoyed because I kept hitting a couple of
issues that have been fixed after 4.3.10. Had a rotten night, yada
yada, and sent the mail.

> (snip)
> Ok, this shows that you really have _NO_ idea how Debian or most other
> Linux distributions work. Go and do your homework before complaining.
> See the according question[2] in FAQ for a start. (Or use a rolling
> release based Linux distribution instead in case you dislike the idea
> of _stable_ _releases_.)
> (snip)
> 		Kind regards, Axel

Not that kind but I deserved it, sorry again, I go sit in corner now
yes.

Mark

Re: Zsh on Debian is beginning to rot

[Axel Beckert]

Hi Mark,

On Sun, Sep 09, 2012 at 08:38:08PM +0200, Mark van Dijk wrote:
> > Squeeze is about 1.5 years old, Squeeze's feature freeze was in the
> > beginning of August 2010 and zsh 4.3.10 was the uptodate zsh
> > developement (!) release back then.
> 
> Yeah, so it's 2 years old and it did have some minor fixes since then.
> The word 'rot' was chosen poorly sorry about that, if I pissed you
> off too much I apologise.

Apology accepted.

And yeah, we felt hurt -- because we put quite a lot of work in
Debian's zsh package, especially over the last 1.5 years since we
started to maintain it as a team. (Despite we're still not where we
would like to be packaging-wise.)

I tried to not sound too pissed, but I seem to have failed there...

> Ok, here's the honest answer. While I indeed do realise how Debian
> works with their versioning strategy (and I commend them for that in
> general) there is a genuine (but admittedly stupid) reason for why I
> sent my email --
[...]
> -- i.e. I did not check the versioning of Zsh properly. For some reason
> the wrong version stuck with me (4.7.13) which is bogative. This
> morning I got a bit too annoyed because I kept hitting a couple of
> issues that have been fixed after 4.3.10. Had a rotten night, yada
> yada, and sent the mail.

Thanks for the explanation. Seems as we've both calmed down again
already. And that's good. :-)

If you do IRC, feel free to come in #pkg-zsh on Freenode.

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

Re: Zsh on Debian is beginning to rot

[Ray Andrews]

On 09/09/12 05:16 PM, Axel Beckert wrote:
> Hi Mark,
>
> On Sun, Sep 09, 2012 at 08:38:08PM +0200, Mark van Dijk wrote:
>>> Squeeze is about 1.5 years old, Squeeze's feature freeze was in the
>>> beginning of August 2010 and zsh 4.3.10 was the uptodate zsh
>>> developement (!) release back then.
>> Yeah, so it's 2 years old and it did have some minor fixes since then.
>> The word 'rot' was chosen poorly sorry about that, if I pissed you
>> off too much I apologise.
> Ah, civility triumphs.
>
>
>
> Gentlemen, this brings up a meta question of mine that I can't find the
> answer too anywhere.  It's off topic, but since we have a genuine Debian
>   packager at hand, maybe he can answer it, or perhaps point me to some
> doc that does explain it.
>
>
>
> Why are Debian packages often so far behind?--vs, say, Arch, who often
> have packages out the day after they are released from upstream?  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.  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.  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.
>
>
>
> 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?  Arch had a package of it out, literally a couple of days
> after it was released.  What is it that Debian packagers do that takes
> so long?  I get the feeling that somehow software packages need to be
> customized and tweaked for a year or two before they can be included.
> Why?  Slackware makes it a point of pride that they don't customize or
> tweak stuff at all, and yet, they too seem to take their time getting
> packages together, and they release a monolithic distro like Debian as
> if (so it might seem) all the parts have to be carefully checked out and
>   mated to all the other parts to avoid disaster.  OTOH, Arch seems to
> feel that you can put things together any way you want and it should all
>   work like lego.  It should all work like lego.
>
>
>
> Or take the current thing, Debian/zsh.  It sounds like Axel has put his
> heart and soul into Debian/zsh, but what on Earth does that involve?
> I'd have thought that zsh is zsh is zsh regardless of the distro.  If
> anyone can help me to get a ground level understanding of this whole
> subject I'd be very obliged.

Re: Zsh on Debian is beginning to rot

[Axel Beckert]

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@lists.alioth.debian.org

* 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@lists.debian.org (for
  usage and general questions) or debian-mentors@lists.debian.org (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@deuxchevaux.org  (Mail)
 X   See http://www.asciiribbon.org/              | abe@noone.org (Mail+Jabber)
/ \  I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Re: Zsh on Debian is beginning to rot

[Vincent Lefevre]

On 2012-09-10 20:42:15 +0200, Axel Beckert wrote:
> There are three full distributions in Debian: stable, testing and
> unstable. (For better overview I ignore oldstable and experimental.)

I wouldn't even say the experimental is a distribution; it's more a
set of packages. By that, I mean that in general, maintainers ignore
dependencies for experimental, so that things may break badly.
Upgrade from experimental packages may also easily break. After
having problems in the past (sometimes affecting new versions in
unstable due to incorrect upgrade), I now avoid experimental (except
occasionally for bug testing); in the future I would only use it in
a specific VM.

Now, this system of fixed distributions is quite rigid, and for more
flexibility, some packages are available in different versions. This
is particularly the case for GCC (e.g., gcc-4.4, gcc-4.5, gcc-4.6,
gcc-4.7, gcc-snapshot, where gcc-snapshot is only available in
unstable, so that it is not affected by the freeze at all).

For zsh, there are zsh and zsh-beta, but I don't really see the point
of having both in stable (this may have been interesting in the past,
but it seems that in the past few years, zsh has evolved slowly enough
so that only one version would be needed in stable). So, how about
removing zsh-beta from testing (hoping that it is not too late) and
make it no longer affected by freezes?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

zsh-beta vs zsh Debian package (was: Re: Zsh on Debian [...])

[Axel Beckert]

Hi,

On Tue, Sep 11, 2012 at 02:15:40AM +0200, Vincent Lefevre wrote:
> On 2012-09-10 20:42:15 +0200, Axel Beckert wrote:
> > There are three full distributions in Debian: stable, testing and
> > unstable. (For better overview I ignore oldstable and experimental.)
> 
> I wouldn't even say the experimental is a distribution; it's more a
> set of packages. 

Yes, it's an add-on to Unstable (or Testing) without propagating the
packages elsewhere (except maybe to Ubuntu ;-), nothing more. That's
why I ignored it as mentioned above. :-)

> For zsh, there are zsh and zsh-beta, but I don't really see the point
> of having both in stable (this may have been interesting in the past,
> but it seems that in the past few years, zsh has evolved slowly enough
> so that only one version would be needed in stable).

I agree.

> So, how about removing zsh-beta from testing (hoping that it is not
> too late) and make it no longer affected by freezes?

Cc'ing the Debian Zsh Packaging Team and Clint for comments as Clint
currently maintains the zsh-beta package.

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

Re: zsh-beta vs zsh Debian package (was: Re: Zsh on Debian [...])

[Clint Adams]

On Tue, Sep 11, 2012 at 01:45:49PM +0200, Axel Beckert wrote:
> > For zsh, there are zsh and zsh-beta, but I don't really see the point
> > of having both in stable (this may have been interesting in the past,
> > but it seems that in the past few years, zsh has evolved slowly enough
> > so that only one version would be needed in stable).
> 
> I agree.

It's a relic of the odd-and-even versioning system that no longer exists.
I kept with it mostly out of inertia and there not seeming to be much
harm in having a snapshot in stable.  I agree that there is also not
much point in having it either.

> Cc'ing the Debian Zsh Packaging Team and Clint for comments as Clint
> currently maintains the zsh-beta package.

I don't mind either way, though if there's any reason an upgrade from
squeeze would remove zsh-beta, maybe it's better to have a transition
package with a symlink to zsh for those few crazy people who use
zsh-beta as their login shell.

Speaking of transitions, did you guys come up with a plan for moving
zsh-beta under the aegis of the group?

Re: zsh-beta vs zsh Debian package (was: Re: Zsh on Debian [...])

[Vincent Lefevre]

On 2012-09-12 00:40:15 +0000, Clint Adams wrote:
> I don't mind either way, though if there's any reason an upgrade from
> squeeze would remove zsh-beta, maybe it's better to have a transition
> package with a symlink to zsh for those few crazy people who use
> zsh-beta as their login shell.

Yes, even though I suspect that people who use /bin/zsh-beta
directly as their login shell should be close to zero. Note that
I do use zsh-beta as my login shell (why not? - If something
breaks, I can easily fix it via root) but by using /bin/zsh as
I chose zsh-beta as the zsh alternative.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)