RFC: What to do with Mozilla

Philip Paeps philip+freebsd at paeps.cx
Thu Oct 16 13:10:14 PDT 2003


On 2003-10-16 15:33:07 (-0400), Joe Marcus Clarke <marcus at marcuscom.com> wrote:
> On Thu, 2003-10-16 at 15:24, Philip Paeps wrote:
> > Yes, that's true.  Expanding on the original braindump would be to use
> > ports like www/mozilla14, www/mozilla15, www/mozilla16 and
> > www/mozilla-firebird which refer to www/mozilla and set de correct
> > pkgnamesuffix and build with the right knobs.
> 
> I think this would get cumbersome if we had to create a new mozillaX
> directory for each version. 

Indeed.  There're a lot of ports being cumbersome these days though (openldap,
bind, postgresql, libtool, autoconf,... to name but a few).

Besides cumbersome, it's also attic-filling in the long run.

> I don't think it's necessary to have every version in the tree forever.
> Previously we tracked the vendor (ultra-stable) track, the stable track, and
> the development snapshot track.  The issue at hand is do we continue with
> three tracks, or is two sufficient.

I was a bit confused about where the vendor bit came into all this.  I've
caught up with my mail now though.  I would go for three ports, www/mozilla
being what mozilla.org deems to be the most stable.  The -vendor is a bit of a
confusing name though (not only to me, apparantly), maybe it could be called
something like -frozen or -previous?

> > It would be nice if we could split out Mozilla as a program and Mozilla as
> > a dependency.  Some things which cite Mozilla as a dependency probably
> > only need Gecko or bits of Gecko, in which case they would specify
> > USE_MOZILLA=gecko and potentially WANT_MOZILLA_GECKO_VER=15 or something
> > to that effect, and they'd magically get something like
> > www[devel?]/mozilla-gecko[15?] as a dependency.
> > 
> > Currently, people (users and maintainers) need to keep track of heaps of
> > versions and ports and are probably spending a lot of time compiling
> > things they'll never use and are never even used internally by the
> > programs depending on them.
> 
> We tried this with the -embedded ports, and it didn't work.  No one used
> them, and they were broken to boot.  

Oh, so that's what they were :-)

Seems I managed to reinvent a deprecated wheel.  Whoopsie.  Sorry about the
noise!

 - Philip

-- 
Philip Paeps                                          Please don't CC me, I am
                                                       subscribed to the list.

  Real programmers don't grumble about the disadvantages
  of Cobol when they don't know any other language.


More information about the freebsd-ports mailing list