Closed Bug 383154 Opened 17 years ago Closed 15 years ago

Seamonkey (suite) NO option to install individual components only

Categories

(SeaMonkey :: Installer, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: worcester12345, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5pre) Gecko/20070604 BonEcho/2.0.0.5pre
Build Identifier: Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/2007060401 SeaMonkey/2.0a1pre

Just noticed the installer always does a full install, and never lets me choose to uncheck the email and composer parts like it used to do even though I choose the "custom" choice. The only thing custom gets me is the ability to not install a desktop shortcut, which is a fix.

Reproducible: Always

Steps to Reproduce:
1. Run the latest installer.
2. Try to install only browser (*no email or other components)
3. Observe.
Actual Results:  
Can't do desired function.

Expected Results:  
Ability to uncheck email and other unwanted components from installer.

This started with the new installer, but I am just now noticing it.
Flags: blocking-seamonkey2.0a1?
Version: unspecified → Trunk
Not blocking, and probably won't even be fixed in the 2.0 release.
The new installer can only make parts of the application optional that are installed as real extensions, and mailnews will probably not be a real extension in this release cycle.
BTW, composer never was optional anyways.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Flags: blocking-seamonkey2.0a1? → blocking-seamonkey2.0a1-
Resolution: --- → WONTFIX
Really now? I think I meant Chatzilla instead of composer. I'd think that any regressions would be fixed before a release, and this certainly qualifies as a regression. Thanks for your explanation, even though I don't completely understand.
Keywords: regression
Keywords: regression
I don't think this is blocking-worthy, but I also think it's reasonable to not want ChatZilla (for emotional/feature check-box/bloat argument reasons, not rational ones - disk space is ~free).
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
The Chatzilla thing is reasonable, but this bug is about browser-only, which we won't do (at least not for 2.0)
Summary: NO option to install browser only → Seamonkey (suite) NO option to install individual components only
Just looking for a confirm as new, and then, if necessary, a WONTFIX. I still would like to be able to install the browser only (I use Thunderbird for email, but like the Suite browser a LOT, and also for testing).

Thanks.
OK, conforming that it just is like that.

I'm not WONTFIXing this, it might be a good idea to keep the report around, but I degrade this to an enhancement request.

The new installer requires us to make all optional components real extensions, from what I know.

Because of this, we will most likely not do browser-only for 2.0, as this would mean we would need to make everything but the browser real extensions, including mail and probably even composer, and I don't think this will happen. We want to make it possible again to exclude chatzilla and venkman, but they need to be converted to register as real extensions, which they currently don't.

Keeping the bug around might be a good idea though, as someone might just re-file it, and there's a possibility that someone might one time come around and make even mailnews and composer register as real extensions.
Until then, making this an RFE targeted for some future.
Severity: major → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
Does it make sense to file new bugs for each of these?

"make it possible again to exclude chatzilla and venkman, but they need to be converted to register as real extensions, which they currently
don't."

Since I don't use them, someone else will have to file those bugs. 

Off topic, but wasn't there originally talk of making the GRE shared by Firefox and Thunderbird, and basically making it like the suite? I guess the thought ws or was that the "less bloated" individual applications actually are more "bloated" in that there is a lot of duplication or overlap. The alternate way of thinking about this is making the suite more modular. If you can point to any discussion on this, I'd appreciate it. Or was this whole concept just dropped? I just remember flow charts and graphics showing exactly this.
Bugs are already filed on making chatzilla and venkman real extensions, some work is even ongoing, not need to file another set.
Filing separate bugs about doing such a thing for composer or mail doesn't make sense as it's enough to have this one around as a reminder for the future - no immediate work is planned on those.

On the off-topic question, just for reference, the thing called "GRE" is dead, but a similar thing is planned with a future shared XULRunner binary and installation, which all of our applications are targeting for the future, but neither the applications nor the core are ready to make this work smoothly yet, so don't expect this to actually work before Mozilla2 (this is Gecko 2.0, not SeaMonkey or Firefox 2, just to be clear).
For Gecko 1.9 / SeaMonkey 2, we will not be there yet.
Do you have the bug numbers for those other ones?

Regarding the off-topic, the quickest reference I could find was: http://forums.mozillazine.org/viewtopic.php?t=21429 , but I remember a flow chart of the programs pointing up toward a shared GRE file, and they all accessed this. I guess this has changed, but I never really saw the update to the model. Thanks.
For venkman and chatzilla, that's bug 392475 and bug 351715 - for the other, the GRE thing was a plan in earlier years but has been abandoned. You'll probably find information its future replacement under the name of "shared XULRunner" or something like that - which is a plan but not done yet.
Depends on: 351715
(In reply to comment #1)
> Not blocking, and probably won't even be fixed in the 2.0 release.
> The new installer can only make parts of the application optional that are
> installed as real extensions, and mailnews will probably not be a real
> extension in this release cycle.

Is it possible to do this in some future release cycle, then? Is there a way to block on a future version?
Actually, with the direction SeaMonkey is moving into, MailNews is an integral part of the suite, so WONTFIXing this.
Status: NEW → RESOLVED
Closed: 17 years ago15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.