Upcoming xulrunner transition

[Andreas Barth]

* Mike Hommey (mh at glandium.org) [080608 08:55]:
> On Sat, Jun 07, 2008 at 10:15:50PM +0200, Andreas Barth wrote:
> > * Mike Hommey (mh at glandium.org) [080607 09:08]:
> > > - I upload both iceweasel and xulrunner rc2 releases to unstable, after
> > >   I'm ready to upload them, and after you tell me I can go on, if my
> > >   network connection permits.
> > 
> > There is this comment from Matthias (doko) about xulrunner which will
> > help us with (not only) this transition:
> > 
> > | - either make the -dev and the -common packages architecture
> > |   dependant. ftp space is not the only thing to consider when
> > |   making a decision about arch/indep packages.
> > |
> > | - or loosen the dependencies; I hardly doubt that the dependencies
> > |   need to be as strict as they currently are. To loosen those the
> > |   package maintainer needs to monitor the upstream changes. This
> > |   is more effort, but can be done, e.g. GCC packaging is done in
> > |   a way to reduce dependencies and to ease transitions. It's more
> > |   effort in package maintainance, but helps overall.
> > 
> > I'd appreciate if you could do these changes - the first one shouldn't
> > be too complicated.
> 
> Only 4 years ago, Steve McIntyre filed bugs on arch-dependent packages
> containing a large amount of arch-independent data. Have things changed
> in the last 4 years ?

I would consider the xulrunner-packages to be the exception to the rule.

Normally, using arch=all-packages is the right thing to do. However, in
case of xulrunner, which is a build-dependency of many central packages
(which means if they fail to build they can block quite many other
packages), I think that archive space (we speak about 11*4 MB = 44 MB)
counts less than saving time of the involved teams.


> Anyways, the second option is out of question, I already spend too much
> time on xulrunner, and don't want to spend more.

I can understand that.


> Now, if only I (or anyone else, actually) had time to fix #246992, which
> is the real problem...

That isn't so trivial - otherwise, it would've been done already. But
yes, that should be done some day. Until that happens however, we should
try to reduce impact in cases it hurts us bad.


> If my network stays in this state for the next few days and I can't
> upload, maybe I can send an interdiff between the last .diff.gz in
> experimental and the new .diff.gz so that someone could upload for me.
> Volunteers?

That'd work. But please tell me what all needs to be uploaded, and in
which order (and sign the interdiff of course :) ). As alternative, you
can send me a signed dsc + diff, and I can do the builds and uploads (so
basically you have a source-only "upload").


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/