[SUGGEST] Reform eclipse and eclipse related ports

[Vizion]

On Friday 21 October 2005 16:59,  the author Roman Neuhauser contributed to 
the dialogue on-
 Re: [SUGGEST] Reform eclipse and eclipse related ports: 

># linimon at lonesome.com / 2005-10-21 17:39:58 -0500:
>> On Fri, Oct 21, 2005 at 03:19:47PM -0700, Michael C. Shultz wrote:
>> > Seems like the quantity of ports available will eventually hit a plateau
>> > with the current two level directory structure.  No one is afraid to
>> > update the basic OS when its needed, even when it means using an entirly
>> > different file system ( ie. UFS1 -=> 2 ),  why be so scared when it
>> > comes to the ports system?
>>
>> Then PLEASE SUBMIT PATCHES.  Tested ones.  Involving portsmon.  Involving
>> the build cluster.  Involving marcusom tinderbox.  Involving FreshPorts.
>> Involving everything in bsd.*.mk.  Involving fixing up all the
>> dependencies after all the thousands of repocopies.
>
>    This is an absurd overreaction.
>
>    FreshPorts is a third party resource, and FreeBSD does change other
>    interfaces also used by other third party software on regular basis.
>
>    The build cluster automation shouldn't limit the utility of ports.
>    BTW, are the scripts publicly available? I don't see anything on
>    http://pointyhat.freebsd.org/ or
>    http://www.freebsd.org/cgi/cvsweb.cgi/
>    If I wanted to update the build cluster code, where would I get it?
>
>    portsmon is your software, and keeping it hostage to changes in
>    ports is IMO unethical.

However rerasonable your other arguments are I don't think it is reasonable to 
suggest that lack of ethics is the problem. FWIW I think the freebsd ports is 
a really good system but, in the light of modern developments, it is in need 
of substantial reconsideration and maybe, in the medium term, total 
re-engineeringhose who have built it have done their best - even if, with the 
benefit of hindsight we can see it would have been better if some things had 
not been gard-wired into it.

The challenge is to find a medium term solution that goes beyond reducing the 
problem to merely dealing with search and browse-- which does nothing to 
address the substantantive issues. I see the only thing we can do in the 
short term, is to make best use of the two tiered system by increasing the 
number of categories and catering for framework centric computing and 
operating system interface layers e.g. eclipse thorugh /usr/ports/eclipse  
and java through /usr/ports/java and then try and find a way to either 
reconstruct or re-design the engineered deficits in the existing system.

But let us not accuse those who have worked on the system in the past of 
unethicality


david

-- 
40 yrs navigating and computing in blue waters.
English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus.
 Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after 
completing engineroom refit.