From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16659 invoked by alias); 10 Sep 2012 18:42:24 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 17254 Received: (qmail 10434 invoked from network); 10 Sep 2012 18:42:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at sym2.noone.org does not designate permitted sender hosts) Date: Mon, 10 Sep 2012 20:42:15 +0200 From: Axel Beckert To: Ray Andrews Cc: zsh-users@zsh.org Subject: Re: Zsh on Debian is beginning to rot Message-ID: <20120910184214.GB5515@sym.noone.org> Mail-Followup-To: Ray Andrews , zsh-users@zsh.org References: <20120909131050.15057aa6@internecto.net> <20120909175104.GV30122@sym.noone.org> <20120909203808.7c627d0c@internecto.net> <20120910001601.GW30122@sym.noone.org> <504E0058.8010802@eastlink.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <504E0058.8010802@eastlink.ca> X-Operating-System: Linux 2.6.32-5-xen-amd64 X-Machine: sym2 x86_64 X-Editor: GNU Emacs 23.2.1 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAAAAAC3mUtaAAAABGdBTUEAALGPC/xhBQAAADh0RVh0U29mdHdhcmUAWFYgVmVyc2lvbiAzLjEwYSAgUmV2OiAxMi8yOS85NCAoUE5HIHBhdGNoIDEuMindFS5JAAACGElEQVQ4jXXQMU8UYRDG8f8shNjdDH4AbpfGDjAWlKiJiZ0ajL1aGCvsNCbGaCGG1koLaztaTYz6ATy+gOyehYmF3MxVxgg3FnDsHcTpJr/M+8w7Rf6nCsaVTTDqxbg9hoOXmw83H71+Eyfg4E1d7/Z2fG9rGkZbTQiu+K+3U/C+76lmkvAhJuDndnoAiftou4V84okAGclop4U/jYACZDTxrYWP0gkxVfAm/W//GLZpxIzwIN0Hn8dw0B+IWkZmQmRsj2HfhwokEklHfNCCiQCRgAR7YyhQVRVTCKCzP4Y5zBBE0t0zY3Q8oQaBqqAMlVEcgVQd9706zGirAFium8HXumlMIeMwqQCInju+2+uB6MRENupdpMt8pRlHZyuAW0F+Mb6XSIVqtxjD+iVmVqqystLEzFTGT92YqRaXpNT5eTVjeJhbALPnrTxLUZUKZsgxcNm64hAOYisT/xhF+oKTGU5RegtC3Rt6eEDi/QnIevdTx9Md2EMmYBRmCQR1026FCGQQJJExsRUqgkMGaWSbwYLnoO4T6VgpbQbdELPMBAHWWrhYrcxXnYgAsatPWygkFCBD4K62MAsOTqA6szYRPpsu6e6Y8mPiVrBMNuGIMrgwBUu4p2DgG1Ownu6hpuTv7hScefHAzAC/yRRw5U5pALMbJ4AUALvHSZhxgHPXTsHcdWD1GadAHr9avP+c0wCr7263Df8ASLwXWHWs+KIAAAAHdElNRQfYBQEBODPr Organization: DeuxChevaux.org -- The =?iso-8859-1?Q?Citr?= =?iso-8859-1?B?b+tu?= 2CV Database User-Agent: Mutt/1.5.20 (2009-06-14) 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)