Difference between revisions of "Talk:Firefox"

Revision as of 08:29, 29 July 2010

Don't you think it's time to clean a little this article - it's getting messy here.

Hmm, yeah, why not - what do you propose to change? Or just change it.

Well, we could move extensions installation to a new single thread and live just FF v1/2/3 packages. Or even get rid of FF2, because everyone who'd like to install v2 should use v3, and if someone has an old computer might have want to use v1.5 (but I haven't checked does FF 1.5 works better than FF 2 or FF 3 on old machines)

What about creating Firefox:Extensions page, and move the extensions there (both pages should link to each other)?

Exactly!

So do it! ;)

I recommend having sections for each version that there is info on the page for, not throwing away the knowledge gained in this wiki. Though I also recommend getting rid of info on especially old versions that are completely outdated, such as Firefox 1.0. I don;t think people here should be making judgements such as "because everyone who'd like to install v2 should use v3" - the systems we setup, where an on-site admin might continue to update Firefox 2.x within the remit of their current software suite, but not have the ability to move to our new suite with Firefox 3 yet, can keep going with 2.x until the time is right; people here shouldn't be supposing they know when precisely people are able to upgrade, when we're only talking about the previous major release series.

Check for file version

Why are you having it check for the existence of the uninstaller? Checking firefox.exe's version would be more convenient. Obviously, firefox.exe's version number does not represent the Firefox version (e.g. 3.0.4), but the Gecko version (e.g. 1.9.0.3224). So instead of

<check type="uninstall" condition="exists" path="Mozilla Firefox (3.0.4)" />

we could have

<check type="file" condition="versiongreaterorequal" path="%PROGRAMFILES%\Mozilla Firefox\firefox.exe" value="1.9.0.3224"/>

Here are the Gecko versions of some other releases: 2.0.0.17 1.8.20080.17373 2.0.0.18 1.8.20081.2918 3.0.4 1.9.0.3224 3.1b1 1.9.1.3202

Why not check the uninstall string?: <check type="uninstall" condition="exists" path="Mozilla Firefox (3.0.3)"/>

When checking the uninstall string, it'll perform a downgrade if the version installed on the client is newer than the one distributed by WPKG.

Isn't our assumption in this wiki that we're in a 'WPKG world' where application updates are managed by WPKG, so the apps installed on a workstation will always be the same or older than those in WPKG? (and in some environments you potentially also even want newer versions downgraded to the WPKG packaged version so that all apps in the organisation are at the same revision, for better IT support through consistency)

Generally yes, but Firefox has its own auto-update mechanism. So a user with admin rights will be prompted to upgrade Firefox by Firefox, possibly before IT gets around to updating Firefox through WPKG. Since Firefox is particularly exposed to security threats it's better for it to be updated to the latest version, even if not done wholly via WPKG.

We turn off Firefox's auto update, because all our user accounts are Limited Windows accounts, so prompting people about an update they don't have the privilige to do anything about can only be an annoyance. I would hope this would be the recommended 'way' that we advise people set systems up at this wiki. In the ill advised situation where people are Administrators (or Power Users?) I agree your point is a good one that at least Firefox remains up-to-date to the latest 3.0.x. However I still maintain that we should have an assumption on this wiki that the admin is doing the right thing and packaging updates as and when they're released and tested. I think by now we've both explained each of our vantages pretty thoroughly :)

Lets say you want to let the auto update mechanism in place (because your users have sufficient rights to do it ; because you do not have the time to update the wpkg managed software in real time), but want to be sure you upgrade Firefox on every machine, especially on the computers where the users never use FF. You can use the condition "versiongreaterorequal" on the firefox.exe file to achieve this. For Firefox 3.0.6 it will be : <check type="file" condition="versiongreaterorequal" path="%PROGRAMFILES%\Mozilla Firefox\firefox.exe" value="1.9.0.3306"/>

Package version confusion and other nonsense

I do not see any reason to not use the application version as the package version.

I do not like people telling me that the package version must be different from the application version. This is the same for hints about needing updates due to security fixes.

This is the WPKG Wiki, which purpose is to show people how to create packages and use WPKG. It is not a site to duplicate information about the reasons, why a software vendor released an update.

<package 
  id="firefox"
  name="Mozilla Firefox"
  revision="%PKG_VERSION%"
  reboot="false"
  priority="10">

  <variable name="PKG_VERSION" value="3.6.8" />

  <check
    type="uninstall"
    condition="versiongreaterorequal"
    path="Mozilla Firefox .+"
    value="%PKG_VERSION%"/>
 
  <install cmd='"%SOFTWARE%\firefox\Firefox Setup %PKG_VERSION%.exe" -ms' />

The above allows me to only change one variable and use it for many other things.

In my recommended best practice, one's own WPKG package 'revision' has no relationship to the program's version number, because you might update your packaging, because you made a mistake or an improvement, separate of any newly released software update from the software vendor. Do you see what I mean? I think that by linking the two, you teach people who're learning WPKG that the WPKG package revision should be identical to the binary application revision, which is definitely not the case. I very much agree with you about people recommending security updates, which is why I often delete such text. Pete Boyd 12:12, 26 July 2010 (CEST)

Per http://wpkg.org/Packages.xml: "revision - user created integer to represent the "version" of the specific WPKG package for this application. Should be incremented when creating a new release. Not to be confused with the software application's version or revision that the WPKG package is for." I've been putting XXX for the revision when I update a package snippet on the wiki, but either 0 or 1 would be acceptable to me. All of the package snippets should be purged of revision=version, and made consistent in other respects such as indentation, newlines, etc. I'm willing to do it but I don't want to overstep. JohnD 20:42, 26 July 2010 (CEST)

In the case, that I made a mistake and have to revise the package, I append .1 or similar to the revision:

<package 
  id="firefox"
  name="Mozilla Firefox"
  revision="%PKG_VERSION%.1"
  reboot="false"
  priority="10">

In addition, I know how many times I had to change the package till I got it right.

The Package documentation telling you to use Integers is only valid for release 0.9 and below, starting with 1.0 you can use dotted revisions.

Starting with 1.x you can use alpha, beta and milestones too.

I will go and update the documentation.

I don't think, it does help anyone to change all the package revisions to XXX or something else.

XXX might even be worse, since it has a negative taste.

If you add a '.1' at the end, what happens for example if Firefox 3.6.8.1 is released? your method would leave room for confusion; you could have 2 sites where you were running WPKG, both with Firefox package 3.6.1 and yet they differed. 'XXX' shows people that they should replace this with their own revision, hwhich is OK but not perfect; I think putting an example '1' would be great; even better would be if that value was incremented by everyone who edited the WPKG package here on the wiki so people could see it had been worked on but getting that to work is extremely unlikely Pete Boyd 10:33, 27 July 2010 (CEST)

If the addition of another dot number is a problem for you, than you can add RC1 and so on. I have used this without problems until now. You may find something else to complain, but it is all depending on the user. If you like to keep integer revisions, do so. I have found that using dates instead of integers gives me better feedback and since WPKG 1.1.2, I can use date and time in the following way too: 2010.07.27-21.48

Anyone can use what he likes, but I still see no reason to force people into using only one way. The examples should reflect the possibilities of WPKG in my opinion. --StefanP 21:52, 27 July 2010 (CEST)

OK. The only thing I have left that I'd like to say in disagreement is that if people who're new to WPKG see the example WPKG package revisions identical to the binary version then they may be led into believing that they _have_ to be identical; and this is made more-so by the use of a %PKG_VERSION% variable. At least this very typical of something that confuses me when I am learning something new. Pete Boyd 22:46, 27 July 2010 (CEST)

I've done a little more digging and it seems that it is entirely intentional that the revision attribute is meant to match the software version number. You can see the discussion in the bug report here: http://bugzilla.wpkg.org/show_bug.cgi?id=120. Since it was added by the main developer I doubt it will be removed. Personally, I don't understand why it needs to be anything other than an integer to indicate that a package definition has changed. The versionCompare function is fairly elaborate, adding about 200 lines of code to wpkg.js, which is almost 3% of the total code. I think the lack of good documentation with examples of best practices contributes to the confusion of new users, for example: http://marc.info/?l=wpkg-users&m=127006465423116&w=2. JohnD 01:16, 28 July 2010 (CEST)

The version comparison function is used to compare any version, so there is no overhead at all. How would you compare file versions without it? StefanP 11:46, 28 July 2010 (CEST)

That's a good point. I withdraw my objection to the function. However, I still believe all of this confusion could be avoided with more clarity in the documentation and consistency in the package snippets throughout the wiki. JohnD 18:21, 28 July 2010 (CEST)

The problem is that not many people take the time to update the documentation, me included. It is a Wiki so anyone can add to and correct it. Who will take the time to revise the silent installers, which is a huge amount, to have the same layout? Sure, if this has been done once, one would only need to revise new additions and changes. StefanP 10:29, 29 July 2010 (CEST)