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

Re: GNOME 2.8 on ia64 completely hosed?



On Sun, Dec 05, 2004 at 02:03:13PM -0500, Adam C Powell IV wrote:
> On Tue, 2004-11-30 at 21:17, Sven Luther wrote:
> > On Tue, Nov 30, 2004 at 01:03:59PM -0700, Al Stone wrote:
> > > Hmmm.  'apt-get upgrade' this morning seems to have fixed it
> > > all -- so it would seem that the autobuilders got caught up.
> > > It would sure be nice to fix the underlying problem, though --
> > > perhaps, as I think someone already suggested, by having a gate
> > > in the process so that the archives are not updated until all 
> > > of the binary packages from a single source package have rebuilt.
> > 
> > No, that is the wrong fix, the right fix is simply to keep all the arch:all
> > packages that have assorted arch:any packages in the archive.
> 
> Uh, that would be called "testing".

No, this is different. The idea is to not remove the older arch:any parts of a
package when a new package is uploaded, simply that at the source level the
unstable archive be consistent for all arches.

Right now, if a source package A contains two packages B (arch: all), and C
(arch: any), if you had version 1 previously in the archive, and are uploading
version 2 on some arch (let's say m68k for the fun of it), and that the
relationship between B and C is that it should be the exact same version of
both which should be in the archive, then during the laps between the upload
of package 2, and the moment all autobuilders have finished uploading it, the
package is uninstallable on arches who have not yet finished rebuilding the
arch (or because version 2 FTBFS on those arches or whatever).

The solution is simple, altough may be complicated to implement. We need only
to allow the archive to contain files indexed by source package, and use not
only the version, but the version per architecture or something such.

> Or are you suggesting that we implement a new fourth distribution
> between testing and unstable, which requires that all arches are built,
> but does not require the 2-10 day testing period?  Sounds kinda
> over-the-top to me.

Let's just not remove the packages from the archive before the new version is
available, and that would be all. Right now a upload in the condition above
done shortly before dinstall run will break all other arches for at least one
day, and there is a simple solution to solve this.

Friendly,

Sven Luther



Reply to: