FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

LinkBack Thread Tools
Old 02-18-2011, 08:12 AM
Mike Hommey
Default What should we do with iceweasel/xulrunner/libmozjs?


Now that squeeze is released, it's time to start pushing new things to
unstable. I've been asked several times already how things would be
evolving in the near future, to which I answered it would quite stay the
way it is now until upstream releases 4.0, at which point I'd upload 4.0
to unstable. But that might change. And I'm hereby requesting feedback
on what fellow developers (especially maintainers of the various reverse
dependencies) think about them.

Here are some of the available options:

- Push 3.6 to unstable and the last 4.0 betas/rc to experimental. Push
4.0 to unstable when it's out.
Pros: More exposure for the 3.6 and 4.0 packages.
Cons: More work for reverse dependencies, which would be made to build
and work with 3.6 and then again with 4.0 in a few weeks.
Last time I checked (which was 3 months ago), 4.0 doesn't work
on s390, sparc and ia64, which would make problems.

- Keep things the way they are (3.5 in unstable, 3.6 in experimental,
4.0 betas on mozilla.debian.net), and upload 4.0 to unstable once it's
Pros: we don't need to make sure everything in unstable builds and
works properly with 3.6 before doing the work again with 4.0 in a
month or so.
Cons: Broken architectures with 4.0.

- Keep 3.5 in unstable, 3.6 in experimental, and push 4.0 to experimental
when it's released.
Pros: We don't break anything in testing/unstable, and we don't have
to deal immediately with the broken architectures.
Cons: We lose version 3.6, which has several advantages over 3.5, and
keep 3.5, which is already very outdated.

- Keep everything in place, prepare rdeps to build and work with 4.0,
and push 4.0 to unstable when everything is ready.
Pros: We don't break anything in testing/unstable, and when 4.0 lands
on unstable, nothing breaks either.
Cons: Past experience shows that it takes a lot of time to fix rdeps.
My gut feeling is that breaking things in unstable would create an
incentive to fix, which doesn't exist when the package is in
experimental or worse, outside the archive.

- Suggest your own if you have better ideas (really, I mean it).

As I mentioned above, my initial idea was to go with the second option,
breaking most rdeps in the process, but then I remembered that 4.0
doesn't work on all our architectures, and I'm hesitating, now.

So, fellow developers, what do you think?


To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110218091242.GA4282@glandium.org">http://lists.debian.org/20110218091242.GA4282@glandium.org

Thread Tools

All times are GMT. The time now is 02:39 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org