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