[gccsdk] Are you happy for me to package Firefox?

alan buckley alan_baa at hotmail.com
Wed Mar 21 02:27:43 PDT 2007


>Peter Naulls <peter at chocky.org> wrote
>In message <d22276c54e.James at ntlworld.com> you wrote:
>
> > I would like to create a package for Firefox using the current binary,
> > and I'm just checking with you first. I'd basically be creating
> > packages for the binary and the ELFLoader, as Tinct and SharedUnixLib
> > are already packaged.
>
>I've taken the liberty of responding to James' private email on this
>list, since the answer is of most relevance here.
>
>What you need to understand is that packing Firefox really isn't that
>much about Firefox at all.  Sure, that's one of the end goals, but you
>need to have something of a holistic view about what problems we're
>trying to solve.  Some of these are presently being hashed out on the
>RiscPkg mailing list - finally there is significant traffic there after
>many years - but there's more.  Alan Buckley has made some good progress
>on others, such as automated packaging, and you will need to coordinate
>with him also.
>

As I don't think I ever got round to mentioning on this list my various
experiments with packageing I thought it would be helpful now.

Over the last year or so I've been trying to get the programs on the
autobuilder to be available to end users via some sort of packaging
mechanism.

In an ideal world I would have liked to package them so they could
all be downloaded via RiscPkg (i.e. in the format for the RISC OS
packaging project).

I did get a few packages working this way, but I had three problems:

1. I had to create a lot of support files and then figure out a way
to update them automatically.

2. Versioning. The idea is that the autobuilder would be run automatically
at fixed intervals. This obviously meant that there was a fresh build of
everything, which would mean I would somehow have to figure out a
way to increase the version number. However in most cases the underlying
program wouldn't have changed, so it would mean that end users would
be constantly told there were upgrades that were not necessary.

3. SharedUnixLibrary and module dependencies. I think these are closer
to being sorted out, but I haven't managed to figure out how they
should be packaged yet.

Currently I've create a much less ambitious packages website, where
it needs just a smaller control record that is just used to create a
file that can be parsed to create a web site where zip files with the
applications can be downloaded from. The results of this can be seen
at:

http://www.riscos.info/packages/

This has exactly the same problem with versioning, but I just ignore
it. Aalthough the version number won't change, you could be
downloading something that says it's the same version, but has been
built at a later date than your last download (possibly with a later
compiler).

I was going to do a few more packages, especially some Chox11
based ones for the website, but have got stuck as I can't build
the X11 libraries on cygwin against GCC3.4.6. (I managed to
get a previous build of Desklib, but then I hit another problem).

I also failed on Debian on a virtual PC.

I know I should really pursue the problems above, but I have
other interests and limited time. I suspect at least some of
the problems would be solved by using the latest GCC compiler,
but I prefer to use a released compiler for programs that
are in turn released.

Currently I've stalled.

Any ideas/comments would be gratefully received.

[snip rest]

Regards,
Alan

_________________________________________________________________
MSN Hotmail is evolving - check out the new Windows Live Mail 
http://ideas.live.co.uk





More information about the gcc mailing list