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

Re: Mozilla NMU (Kitame, *please* read!)

On Sat, Jun 09, 2001 at 04:26:12PM +0100, Robert McQueen wrote:
> On Sat, Jun 09, 2001 at 05:42:23AM -0800, Ethan Benson wrote:
> > keep in mind that these (mozilla, nautilus, galeon et al) are large
> > packages and should get a decent ammount of time to live in
> > unstable/testing so they can, well, be tested and get stabilized for
> > when woody finally becomes stable.  at the rate we are going that is
> > not going to happen.  
> I thoroughly agree. That is why a non-crypto Mozilla should be uploaded
> to main ASAP so that it and the other packages can be thoroughly tested
> and stabilised in good time. The re-addition of crypto to either main or
> non-US is a relatively minor change and can be done later on.

i non-crypto mozilla is likely to be broken.  and i think it will get
very little testing since everyone will simply continue doing what
they do now, either compiling it themselves or getting various
unoffcial packages.  

> After uploading a non-crypto mozilla to main and removing the threat of
> any NMUs and such, the next step would of course be to ensure that

whats wrong with an NMU?  the current situation is absurd. just upload
a full crypto enabled version to non-US and try moving it into main
later *IF* it becomes possible. 

> crypto is available, either in a replacement package in non-US or so, or
> ideally as you say, a PSM package that can be built and uploaded
> seperately. Either way, it will get done, be made available, be
> explained in the README.Debian, and will not result in breaking Mozilla.
> The PSM breakage at the moment will be the same if it's built
> with or seperately from Mozilla, and is more likely a libnspr problem as
> I said.

frankly i don't buy it.  mozilla developers can't even fix it so it
runs in read-only directories correctly.  how can you expect them to
have left psm in a moduler and easily removable state?  

besides that i think it should happen the other way around, upload a
full uncrippled, crypto enabled version NOW, to non-US and then try and
put it in main later when and *if* that becomes possible.  if it never
becomes possible then who cares non-US is where it will live.   

> Excellent. I hope you can see that this is a more reasonable compromise
> that will result in everything being resolved by release time, and in
> the mean time letting people get on with their testing and packaging of
> Mozilla-dependers.

wasting time on crypto cripped builds is not a compromise i want to
see made.  it would be nothing but a waste of archive space.  

people want a browser with crypto, if you put a crippled version in
main nobody will use it, they will just laugh at how stupid it is and
go get a build from somewhere else.  

Ethan Benson

Attachment: pgpMSsMCqrYNG.pgp
Description: PGP signature

Reply to: