discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Update GNUstep on Debian to more recent version?


From: Yavor Doganov
Subject: Re: Update GNUstep on Debian to more recent version?
Date: Wed, 19 Dec 2007 08:52:11 +0000 (UTC)
User-agent: Pan/0.132 (Waxed in Black)

В Wed, 19 Dec 2007 08:14:23 +0100, Dr. H. Nikolaus Schaller написа:

> Software-publishing-psychology suggests a timing of minor
> updates every 6 weeks.

It seems that you have installed the current Debian stable release, 
a.k.a. "Etch".  Packages there are updated only when a security-related 
or critical bug is found.  The next stable release is expected at the end 
of 2008, although it might be delayed a bit.

> Is there a method in Debian to partially update the distro, i.e. choose
> which branch the package manager looks at?

Yes, /etc/apt/sources.list.  Upgrading from stable -> testing -> unstable 
is not guaranteed to work.  Basically, you need to change the entries in 
that file to `testing' and do `aptitude dist-upgrade', then change to 
`unstable' and repeat that step (if you're willing to upgrade to 
unstable, of course).

Current Debian sid has Gorm 1.2.2; the other packages are also up to date 
with a few exceptions.  The GNUstep stack is about to migrate to testing 
in the very near future (next weeks, if we resolve all issues).

> Before someone draws false generalized conclusions - the Aug 06 GORM
> crashes for me only when trying to save a special set of given .gorm
> files in Cocoa NIB format.

Please file a bug report (`reportbug gorm.app' or `M-x debian-bug RET p 
RET gorm.app RET' if you use Emacs).  I'll try to reproduce this on a 
stable box.

> Does someone know how such updates are made available by Debian?

Packages are uploaded to unstable (a.k.a. `sid') and migrate to `testing' 
when they pass the quarantine period (usually 10 days), are built on all 
official architectures, do not have release-critical bugs and are not 
tied to other transitions (for example, popplerkit.framework cannot 
migrate if it depends on poppler >= 0.6 until all poppler-depending 
packages are built, installed, and ready to migrate).

In addition, there is `experimental' suite, which is not self-contained 
(i.e. it can be used only together with `unstable').

When Debian is about to release, `testing' is frozen (the toolchain 
first, then everything else) and updates propagate after review from the 
release team.  When all bugs in the distribution are fixed, testing is 
declared stable and usual packages migration sid -> testing is open 
again.  The cycle then repeats.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]