RFC: What to do with Mozilla
jbryant at democrats.com
Thu Oct 16 14:05:31 PDT 2003
On a related subject, given that firebird and thunderbird are
essentially "unbundled" would it not make sense to create a subheirarchy
under the relative directory nodes [www/firebird/firebird,
www/firebird/extensionA, www/firebird/extensionB, etc]?
Just an observation after looking at the extensions page for firebird, I
would imagine ports/www would get relatively cluttered, and honestly,
`make search` in /usr/ports comes up with a lot of unwanted junk for any
real search. I recently saw other suggestions to the lists to further
subdivide the ports heirarchy for another group of ports, and this is
really beginning to make sense. The current groupings are not intuitive.
Another good example for this would be like xmms, and others...all sorts
of plugins mixed all over the ports tree for xmms, and they are a pain
in the ass to find via `make search`.
just my two cents.
I would also like to propose a new subtree under ports: ham-swl. I am
in the process of porting over five or six apps now for amateur radio
use, and having a ports subtree for such use might encourage more
development and porting along these lines.
Philip Paeps wrote:
>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
> - Philip
73 de Jim, KC5VDJ
"Religious fundamentalism is the biggest threat to international security that exists today."
United Nations Secretary General B.B.Ghali, 1995
"The Fascist State organizes the nation, but leaves a sufficient margin of liberty to the individual;
the latter is deprived of all useless and possibly harmful freedom..." -- Benito Mussilini, 1932
http://www.pbs.org/now/politics/patriot2-hi.pdf -- The GOP agrees
More information about the freebsd-ports