Re: [SUGGEST] Reform eclipse and eclipse related ports
Wes Peters
On Oct 14, 2005, at 10:30 PM, Mark Linimon wrote:
> On Fri, Oct 14, 2005 at 09:15:07PM -0700, Wes Peters wrote:
>
>> I don't mind moving the eclipse ports from java to devel, but all the
>> other eclipse ports are add-ins to eclipse and should probably be
>> classified along with eclipse.
>
> [adding freebsd-java to the Cc:]
>
> For some background, there's been on-and-off discussion on -java
> about how the java category was never really a good idea. None of
> the other languages have their own primary category. In particular
> we've completely failed to train our users to send 'java' PRs only
> for problems with the JVMs and 'ports' PRs for things in ports/java.
Makes you wonder how much the rest of the ports system would be
cleaned up with a 'perl' category and all those p5-something-
something ports got tossed into that basket, doesn't it?
>> In particular, if eclipse is a 'devel' tool, I don't see how CDT
>> and phpeclipse are editors. GEF isn't a graphics library, it's a
>> graphical emulation framework for eclipse, which is (again) a
>> development tool.
>
> Well, Eclipse is one of these 'suites' that doesn't really fit well
> in one particular category. You could make the same argument about
> OpenOffice, opengroupware, ZendStudio, and so forth. (These 3 are
> chosen deliberately because they're scattered in 3 different
> categories).
>
> OpenBSD has a 'productivity' category although what it has in it is
> more
> like our 'deskutils'. Perhaps we should consider co-opting that name?
I don't know that 'productivity' really describes what these are. In
particular, I'm not sure if opengroupware adds productivity or
subtracts it. ;^) Ditto for eclipse, for that matter. A category
name that means 'big blobs of software with lots of options' might be
appropriate.
> (Our "deskutils" is a combination of things like calendar programs and
> individual GNOME add-ons, so it's a little bit of a mixed bag.
> However,
> I'm not sure I can see Eclipse fitting in with those).
>
> There is also the fact to consider that at 1624 ports, devel is simply
> too huge for its own good. Everything is in there including the
> kitchen sink.
devel is one of several categories that has grown useless; www is
another. It's certainly worth thinking about a category that
actually makes sense for these large software systems like openoffice
and eclipse.
> Even if we just went with an 'ide' category, there are still 27 ports
> that would probably fit in there. Not a lot in my book (and I've
> always
> been against anything that would lead us towards having hundreds of
> categories), but I could see an argument for it, even so.
>
> I'll leave the idea of completely reshuffling all the categories for
> another time, since everyone is probably tired of listening to my own
> particular views on that.
>
> mcl
>
--
Where am I, and what am I doing in this handbasket?
Wes Peters
w...@softweyr.com
Mark Linimon
> Makes you wonder how much the rest of the ports system would be
> cleaned up with a 'perl' category and all those p5-something-
> something ports got tossed into that basket, doesn't it?
I do _not_ recommend we attempt to do the 1688 (one thousand six hundred
eighty-eight) repocopies, even if anyone was insane enough to volunteer
to try to do so.
It would take months to sort through the damage to the depedency tree,
during which time the ports tree would effectively be broken. No matter
how much we tested it first, we would never get them all. And, of course,
we'd have to have the tree frozen to run the regression test, or the test
would become instantly obsolete the second we ran it.
Nothing to see here, folks. Move along.
mcl
Norikatsu Shigemura
Norikatsu Shigemura <no...@freebsd.org> wrote:
> Hi eclipse and eclipse related ports maintainers and users!
> Some time ago, someone suggested that eclipse and eclipse
> related ports should be located on proper categories. I
> think so. So I suggest following repocopy list. Anyone,
> do you have any idea?
Oops, I missed. Eclipse is very similar to Emacs:
1. IDE
Emacs is a one of IDE(or platform). And anyone doesn't
think that it is ONLY a elisp interpreter. But it is
a editor. So I think that it is no problem that Eclipse
may be categolize to editors.
2. Extension-able
Emacs has many extention modules like news reader, language
support, games, ...
3. Mode
Emacs has many mode for descriptions like C, Perl, Java, ...
4. others
It must be that there are other similar feature:-).
java/eclipse -> editors/eclipse
java/eclipse-EPIC -> editors/eclipse-EPIC
java/eclipse-cdt -> editors/eclipse-cdt
java/eclipse-checkstyle -> devel/eclipse-checkstyle
java/eclipse-clay-core -> databases/eclipse-clay-core
java/eclipse-devel -> editors/eclipse-devel
java/eclipse-emf -> editors/eclipse-emf
java/eclipse-examples -> devel/eclipse-examples
java/eclipse-gef -> editors/eclipse-gef
java/eclipse-gef-examples -> editors/eclipse-gef-examples
java/eclipse-langpack -> editors/eclipse-langpack
java/eclipse-log4e -> editors/eclipse-log4e
java/eclipse-lomboz -> devel/eclipse-lomboz
java/eclipse-pmd -> devel/eclipse-pmd
java/eclipse-quantum -> databases/eclipse-quantum
java/eclipse-sqlexplorer -> databases/eclipse-sqlexplorer
java/eclipse-sysdeo-tomcat -> www/eclipse-sysdeo-tomcat
java/eclipse-uml -> editors/eclipse-uml
java/eclipse-v4all -> editors/eclipse-v4all
java/eclipse-vep -> editors/eclipse-vep
java/eclipse-vep-examples -> editors/eclipse-vep-examples
java/eclipse-viplugin -> editors/eclipse-viplugin
java/eclipseme -> devel/eclipseme
java/phpeclipse -> editors/phpeclipse
Mark Linimon
> I don't mind moving the eclipse ports from java to devel, but all the
> other eclipse ports are add-ins to eclipse and should probably be
> classified along with eclipse.
[adding freebsd-java to the Cc:]
For some background, there's been on-and-off discussion on -java
about how the java category was never really a good idea. None of
the other languages have their own primary category. In particular
we've completely failed to train our users to send 'java' PRs only
for problems with the JVMs and 'ports' PRs for things in ports/java.
> In particular, if eclipse is a 'devel' tool, I don't see how CDT
> and phpeclipse are editors. GEF isn't a graphics library, it's a
> graphical emulation framework for eclipse, which is (again) a
> development tool.
Well, Eclipse is one of these 'suites' that doesn't really fit well
in one particular category. You could make the same argument about
OpenOffice, opengroupware, ZendStudio, and so forth. (These 3 are
chosen deliberately because they're scattered in 3 different categories).
OpenBSD has a 'productivity' category although what it has in it is more
like our 'deskutils'. Perhaps we should consider co-opting that name?
(Our "deskutils" is a combination of things like calendar programs and
individual GNOME add-ons, so it's a little bit of a mixed bag. However,
I'm not sure I can see Eclipse fitting in with those).
There is also the fact to consider that at 1624 ports, devel is simply
too huge for its own good. Everything is in there including the
kitchen sink.
Even if we just went with an 'ide' category, there are still 27 ports
Panagiotis Astithas
Although I agree with everything you say here, I can't see how this is
an argument against the fact that GEF and CDT most probably belong to
devel. Unless I'm mistaken and you were not making one?
Regarding the splitting of devel and www categories, perhaps we should
wait until the port tree migrates to subversion (yeah, right :-))?
Cheers,
Panagiotis
Vizion
dialogue on-
Re: [SUGGEST] Reform eclipse and eclipse related ports:
My solution is not popular even if it is logical.
I say the ports structure needs a strategy that takes account of the reality
of tools such as eclipse and soes not hesititate to create entirely new
categories to meet those new neeeds. When the ports tree logic was defined
(long ago in comparative computer history) it structure fitted well.
We now need something like
ports/eclipse
where all the tools that form part of the eclipse fremework can be grouped
together.
But this view does not dit well with those who feel there is a virtue in
preserving the existing structure which I cannot help but regard as an
anachronism for these newly emerging frameworks which do not fit well into
the traditional structure.
david
>>
>> mcl
>
>--
> Where am I, and what am I doing in this handbasket?
>Wes Peters
>w...@softweyr.com
>
>_______________________________________________
>freebs...@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
--
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.
Wes Peters
On Oct 15, 2005, at 2:39 AM, Panagiotis Astithas wrote:
> Mark Linimon wrote:
>
>> On Fri, Oct 14, 2005 at 09:15:07PM -0700, Wes Peters wrote:
>>
>>> I don't mind moving the eclipse ports from java to devel, but all
>>> the other eclipse ports are add-ins to eclipse and should
>>> probably be classified along with eclipse.
>>>
>> [adding freebsd-java to the Cc:]
>> For some background, there's been on-and-off discussion on -java
>> about how the java category was never really a good idea. None of
>> the other languages have their own primary category. In particular
>> we've completely failed to train our users to send 'java' PRs only
>> for problems with the JVMs and 'ports' PRs for things in ports/java.
>>
>>> In particular, if eclipse is a 'devel' tool, I don't see how CDT
>>> and phpeclipse are editors. GEF isn't a graphics library, it's
>>> a graphical emulation framework for eclipse, which is (again) a
>>> development tool.
>
> Although I agree with everything you say here, I can't see how this
> is an argument against the fact that GEF and CDT most probably
> belong to devel. Unless I'm mistaken and you were not making one?
I was making an argument that regardless of where eclipse migrates
too, all of it's little pieces should go right along with it, rather
than getting spread all over the ports system.
> Regarding the splitting of devel and www categories, perhaps we
> should wait until the port tree migrates to subversion (yeah,
> right :-))?
Or hell freezes over, whichever happens first?
Mark Linimon
> >Regarding the splitting of devel and www categories, perhaps we
> >should wait until the port tree migrates to subversion (yeah,
> >right :-))?
>
> Or hell freezes over, whichever happens first?
/me does a poll to see how many people want to do 500-1000 repocopies.
Hands? Anyone?
mcl
Panagiotis Astithas
>
> On Oct 15, 2005, at 2:39 AM, Panagiotis Astithas wrote:
>
>> Mark Linimon wrote:
>>
>>> On Fri, Oct 14, 2005 at 09:15:07PM -0700, Wes Peters wrote:
>>>
>>>> I don't mind moving the eclipse ports from java to devel, but all
>>>> the other eclipse ports are add-ins to eclipse and should probably
>>>> be classified along with eclipse.
>>>>
>>> [adding freebsd-java to the Cc:]
>>> For some background, there's been on-and-off discussion on -java
>>> about how the java category was never really a good idea. None of
>>> the other languages have their own primary category. In particular
>>> we've completely failed to train our users to send 'java' PRs only
>>> for problems with the JVMs and 'ports' PRs for things in ports/java.
>>>
>>>> In particular, if eclipse is a 'devel' tool, I don't see how CDT
>>>> and phpeclipse are editors. GEF isn't a graphics library, it's a
>>>> graphical emulation framework for eclipse, which is (again) a
>>>> development tool.
>>
>>
>> Although I agree with everything you say here, I can't see how this
>> is an argument against the fact that GEF and CDT most probably belong
>> to devel. Unless I'm mistaken and you were not making one?
>
>
> I was making an argument that regardless of where eclipse migrates too,
> all of it's little pieces should go right along with it, rather than
> getting spread all over the ports system.
Since you snipped Mark's reply in your quote, let me clarify that my
comments above were directed to Mark and I agree with your point.
However I'm not sure whether there has to be a strict rule that every
eclipse-foo port should go in the same category. Perhaps the emacs
precedent should be followed. See below.
This sounds fine, too.
Cheers,
Panagiotis
Roger Marquis
> My solution is not popular even if it is logical.
Honestly David, until you can make a better case your solution
doesn't seem logical either.
>I say the ports structure needs a strategy that takes account of
>the reality of tools such as eclipse and soes not hesititate to
>create entirely new categories to meet those new neeeds.
Before doing that you really need to define what constitutes a port
category i.e, a set of rules which can universally applied. This
definition would need to encompass all ports, not just the one
you're concerned about today, and do so in a way that is
self-evident and at has some consensus among port maintainers.
> We now need something like
> ports/eclipse
That would be the worst solution I could think of, but thanks for
making your special interest clear. We can see by this it is a
religious issue and the integrity of the ports collection is less
important than your particular application. Since you are not
similarly advocating ports/netbeans or ports/emacs the proposition
is logically indefensible.
> But this view does not dit well with those who feel there is a virtue in
> preserving the existing structure which I cannot help but regard as an
> anachronism for these newly emerging frameworks which do not fit well into
> the traditional structure.
You've outlined several possible frameworks where there's really
only room for one. Choose wisely.
[ ] existing
[ ] emerging
[ ] traditional
[ ] structure
--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/
Vizion
From: Vizion <viz...@vizion.occoxmail.com>
To: freebs...@freebsd.org
CC: Panagiotis Astithas <pa...@ebs.gr>, Wes Peters <w...@softweyr.com>,
t...@pinguru.net, w...@FreeBSD.org, freebsd...@FreeBSD.org,
mit...@riken.jp, Norikatsu Shigemura <no...@FreeBSD.org>,
rtd...@cytherianage.net, sugi...@jp.FreeBSD.ORG, Mark Linimon
<lin...@lonesome.com>, freebs...@FreeBSD.org
On Sunday 16 October 2005 03:20, the author Panagiotis Astithas contributed
to the dialogue on-
Re: [SUGGEST] Reform eclipse and eclipse related ports:
Sounds crazy to me...
Scattering eclipse tools over the whole ports collections is, to my mind, a
retrograde, rather than a positive step. There are another 290 pus eclipse
tools to bring on board!!
I would continue to advocate for a single collection
david
Herve Quiroz
> Sounds crazy to me...
> Scattering eclipse tools over the whole ports collections is, to my mind, a
> retrograde, rather than a positive step. There are another 290 pus eclipse
> tools to bring on board!!
> I would continue to advocate for a single collection
We already discussed this matter some time ago. And the discussion just
died by itself IIRC. You keep telling us about the "290 eclipse tools"
that exist all around the world but what I just see:
$ ls /usr/ports/java | grep eclipse | wc -l
--> 24
So we are speaking of 24 ports here. Nothing close to 290 if you ask me.
Besides, you keep whining about the poor philosophy behind the whole
ports framework and speaking of the closed-mind of its developers who
cannot see the "pure true genious solution" that you suggested. I don't
really think this will encourage people to try and understand your
approach.
Fine. As it was the case with the latest discussion we had on the
subject, I think I'll just find another way to spend my time and energy
(shooting PRs or discussing and fixing the existing framework).
Herve
Wes Peters
On Oct 16, 2005, at 3:20 AM, Panagiotis Astithas wrote:
> Wes Peters wrote:
>
>> On Oct 15, 2005, at 2:39 AM, Panagiotis Astithas wrote:
>>>
>>> Although I agree with everything you say here, I can't see how
>>> this is an argument against the fact that GEF and CDT most
>>> probably belong to devel. Unless I'm mistaken and you were not
>>> making one?
>>>
>> I was making an argument that regardless of where eclipse
>> migrates too, all of it's little pieces should go right along
>> with it, rather than getting spread all over the ports system.
>
> Since you snipped Mark's reply in your quote, let me clarify that
> my comments above were directed to Mark and I agree with your
> point. However I'm not sure whether there has to be a strict rule
> that every eclipse-foo port should go in the same category. Perhaps
> the emacs precedent should be followed. See below.
That's exactly the point I was (and am) trying to argue against. I
have to resort to 'make search' to find emacs tools these days
because they've been thrown all over the ports system by well-meaning
but misguided contributors, and I'd hate to see that happen to
eclipse tools too.
As to devel vs. editors, eclipse is hardly a text editor. Emacs at
least started that way.
Vizion
to the dialogue on-
Sounds crazy to me...
Scattering eclipse tools over the whole ports collections is, to my mind, a
retrograde, rather than a positive step. There are another 290 pus eclipse
tools to bring on board!!
I would continue to advocate for a single collection
Achilleus Mantzios
Perhaps i missed something,
but why all that bother with eclipse, when (at least) all the
java add-ons for it are easily managed by the tool itself?
For possible JNI eclipse plugins (if any) a port definately
makes sense but for the majority (java) i think the community
over engineers the case instead of working on more vital issues
of the operation system.
I am not quoting directly any of the fellows participating in the
discussion, i just grabbed the last email to write my lines.
>
> Wes Peters
> w...@softweyr.com
>
> _______________________________________________
> freebs...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-java
> To unsubscribe, send any mail to "freebsd-java...@freebsd.org"
>
--
-Achilleus
Petr Valenta
I agree,
many people don't need eclipse and puting it into whole port collection is bad because there will be no way to disable fetching eclipse-* with cvsup...I think that /usr/ports/eclipse/ will be the best solution.
Petr
>
> --
> 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.
Herve Quiroz
> I agree,
> many people don't need eclipse and puting it into whole port
> collection is bad because there will be no way to disable fetching
> eclipse-* with cvsup...I think that /usr/ports/eclipse/ will be the
> best solution.
Actually I believe you can set up a refuse file to disable fetching
Eclipse stuff with cvsup. Something like that should do the trick:
$ find /usr/ports -type d -name 'eclipse*' -mindepth 2 -maxdepth 2 \
| sed 's|^/usr/||' >> <location of your refuse file>
Anyway, I don't think this is really an issue...
Herve
Herve Quiroz
On Sun, Oct 16, 2005 at 06:55:25PM -0700, Wes Peters wrote:
> That's exactly the point I was (and am) trying to argue against. I
> have to resort to 'make search' to find emacs tools these days
> because they've been thrown all over the ports system by well-meaning
> but misguided contributors, and I'd hate to see that happen to
> eclipse tools too.
Greg (glewis@) already suggested to create a new *virtual* category for
Eclipse ports to ease the search of a port. That could do the trick...
Or else you may just use FreshPorts.org facilities to look for an
Eclipse plugin:
Again, I don't think we should make an exception of Eclipse. All other
ports comply to the convention and for instance there is no 'apache'
non-virtual category. Regarding Apache, we are speaking of at least 116
'mod_*' ports while there are only 24 eclipse ports. Moreover, 'apache'
is not even a virtual category. But that's probably because all 'mod_*'
ports are in the same 'www' non-virtual category.
So my take is that either we group all Eclipse ports into the same
non-virtual category (but not a new 'eclipse' category which makes no
sense) or we scater them but tag them by having them all in the
'eclipse' virtual category.
Herve
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>On Monday 17 October 2005 08:30, the author Herve Quiroz contributed to the
>dialogue on-
>
> Re: [SUGGEST] Reform eclipse and eclipse related ports:
>You guys just do not get it.
>
>I have spent over 45 five years in the computer industry and am fed up with
>technologists who think in terms of their precious systems rather than on
>behalf of people that use them.
>
>You do not get it that the ports systems, as currently configured, is out
> of date as far as the newly emerging framework centric applications model
> as against the traditional application centric model.
>
>e now need a category /ports/eclipse and not this ridiculous scattering
> arounf the system or some half hearted 'virtual' solution that gets in the
> way of a real framework centric solution.
>
>I am sick to death of hearing the same old appeal based on "mot making an
>exception" which really means "I want to bury my head in the sand" and stick
>to the old ways of doing things.
>
>And before anyone tells me -- yes I am angry.
>
>david
>
>>Herve
>>_______________________________________________
>>freebs...@freebsd.org mailing list
>>http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>>To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
Vizion
dialogue on-
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>[recipient list trimmed down]
Petr Valenta
Of course,
but I thinks that /usr/ports/eclipse is much more transparent but it's only my feeling.
Petr
Jan Grant
> You guys just do not get it.
>
> I have spent over 45 five years in the computer industry and am fed up with
> technologists who think in terms of their precious systems rather than on
> behalf of people that use them.
This is an open-source project; patches speak louder than words. There
is a process outlined in the porters' handbook (that I've pointed you at
before) for getting ports system rejigs to even be considered.
(Given the ability of existing tools to search for ports in "half-assed"
virtual categories, I think you overstate your case.)
Cheers,
jan
--
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44 (0)117 3317661 http://ioctl.org/jan/
HP-unix: Open Sauce product, available in 57 distributions.
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>On Mon, 17 Oct 2005, Vizion wrote:
>> You guys just do not get it.
>>
>> I have spent over 45 five years in the computer industry and am fed up
>> with technologists who think in terms of their precious systems rather
>> than on behalf of people that use them.
>
>This is an open-source project; patches speak louder than words. There
>is a process outlined in the porters' handbook (that I've pointed you at
>before) for getting ports system rejigs to even be considered.
>
>http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-c
>ategories.html#PROPOSING-CATEGORIES
>
>(Given the ability of existing tools to search for ports in "half-assed"
>virtual categories, I think you overstate your case.)
>
Sorry but those who think this way do not get it..
You cut out a highly significant part of my posting so I repeat it in full.
>> I have spent over 45 five years in the computer industry and am fed up with
>>technologists who think in terms of their precious systems rather than on
>>behalf of people that use them.
Your response :
> patches speak louder than words.
Gives additional weight to my words. You are reinforcing my point. The
division between the perceptions of a technological old guard and the emrging
needs of a new breed of users whose attitudes come from a user's appreciation
of the extra-technological implications of technological changes. I would
argue that the technologist is always one step behind the consumer in
appreciating the realworld potential of the products of technology.
I saw microsoft meteoric rise just because those who were providing patches
and code in the **ix fraternity would not listen to the demands of system
users. The technologist who thought in terms of system did not heed the needs
of users.
The problem can be both identified and summarized by the notion of that
technological competence needs non-technological direction if it is going to
be produce results that are socially sustainable.
I would appreciate it if, in the light of the history of modern day computing,
you would not so obviously seek to belittle the voices of those who do not
see things through an internal FreeBSD methodolgical filter.
>>You do not get it that the ports systems, as currently configured, is out
>>of date as far as the newly emerging framework centric applications model
>>as against the traditional application centric model.
Framework centric applications need their own hierarchy so that plugins can be
managed within the hierarchy. So my comment:
>>We now need a category /ports/eclipse and not this ridiculous scattering
>>arounf the system or some half hearted 'virtual' solution that gets in the
>>way of a real framework centric solution.
Was, I feel, more apt than your response:
>(Given the ability of existing tools to search for ports in "half-assed"
>virtual categories, I think you overstate your case.)
Which shows again how those who think that way do not get it.
The issue is not about searching it is about having a hierarchy that works for
a framework centric processing model!
Your response:
>There is a process outlined in the porters' handbook (that I've pointed you
> at before) for getting ports system rejigs to even be considered.
Shows again do not get it. You do not think about user you are thinking about
users can be made to work with current internal regulatory processes. This
approach can be seen as somewhat condescending.
The user does not want to be embroiled in the process of determining how user
needs are to be met or weighed down by a bureaucracy that was devised to meet
yesterday's problems. Those who maintain/create the bureaucracy need to find
ways of usig their accumulated wisdom to help recreate and reconfigure rather
than demand that others jump through hoops.
It was the failure of the **ix community to modify its relationship to its
users that led to the rise of the poorer technology of microsoft.
Those of us within the Freebsd community need to grasp the fact that the
future of comuting applications lies increasingly in common framework centric
approaches to processing that encompass common developmental and application
interfaces. hence division by application type (which is how ports are
categorized) is not the way to go.
>>I am sick to death of hearing the same old appeal based on "mot making an
>> exception" which really means "I want to bury my head in the sand" and
>>stick to the old ways of doing things.
>>And before anyone tells me -- yes I am angry.
And will probably stay angry until some of the old guard begin to get it and
not just in this area.
I do not want FreeBSD to finish up as just another carrier for Linux
applications. It is not enough to satisfy our existing user base. It is not
enough to stick to the ways things have been done in the past.
The ports system is fantastic BUT it is now showing its age.
The freedsd docs system is incredibly good but it does not provide context
driven help.
The freebsd install system is good but it does not have a user ventric
installation process.
The configuration system needs a web interface.
If all our energies go towards increasing system functionality rather then
identifying how we can catching up on user convenience then in the battle for
tomorrow's users we will lose out to competition.
Will will finish up satisfying our technological impulses and losing touch
with our potential place in tomorrow's world
My two pennorth
david
Roman Neuhauser
> [recipient list trimmed down]
>
> On Sun, Oct 16, 2005 at 06:55:25PM -0700, Wes Peters wrote:
> > That's exactly the point I was (and am) trying to argue against. I
> > have to resort to 'make search' to find emacs tools these days
> > because they've been thrown all over the ports system by well-meaning
> > but misguided contributors, and I'd hate to see that happen to
> > eclipse tools too.
>
> Greg (glewis@) already suggested to create a new *virtual* category for
> Eclipse ports to ease the search of a port. That could do the trick...
Wes said: "I have to resort to 'make search'" which presumably means
he'd prefer to just ls /usr/ports/$emacs_category; while 'make
search' is a bearable interface (FMPOV), you can't beat a ls.
Hey, what about materialized virtual categories? A bunch of
symlinks, and everyone's happy. Or is that too much for CVS?
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
Scot Hetzel
> Wes said: "I have to resort to 'make search'" which presumably means
> he'd prefer to just ls /usr/ports/$emacs_category; while 'make
> search' is a bearable interface (FMPOV), you can't beat a ls.
>
> Hey, what about materialized virtual categories? A bunch of
> symlinks, and everyone's happy. Or is that too much for CVS?
>
modify bsd.port.mk to create the virtual category directories and then
symbolicly link the ports into these categories.
The following could be added to bsd.port.mk
virtualport:
.for CATEGORY in ${CATEGORIES}
.if not exist ${PORTSDIR}/${CATEGORY}
mkdir ${PORTSDIR}/${CATEGORY}
.endif
.if not exist ${PORTSDIR}/${CATEGORY}/${PORTNAME}
ln -s ${.CURDIR} ${PORTSDIR}/${CATEGORY}/${PORTNAME}
.endif
.endfor
which would add the link for a specific port. The we would need to
add a virtualports target (bsd.subdir.mk?) that would decend thru all
the ports creating all the symbolic links (similar to the "make
readmes" target used in /usr/ports/ ).
Also there would need to be another target that would remove all the
symbolic links, that way you could re-create them without worrying
about removed symbolic links pointing to non-existant ports.
NOTE: Non of this code has been tested. If you want this feature, work
on improving the code and submitting it as a patch to the PR database
for Ports Managers to accept/reject.
Scot
--
DISCLAIMER:
No electrons were mamed while sending this message. Only slightly bruised.
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>On 10/17/05, Roman Neuhauser <neuh...@sigpipe.cz> wrote:
Would this provide an opportunity to have for example:
/usr/ports/eclipse
/usr/ports/eclipse/plugins/
so that the plugins could be selected for installation from make config
in /usr/ports and manage the installation of the plugins (rather similar to
what happens for php)?
david
>--
>DISCLAIMER:
>No electrons were mamed while sending this message. Only slightly bruised.
>_______________________________________________
>freebs...@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
Panagiotis Astithas
This can be done today, with an eclipse-plugins meta-port, similar to
the php5-extensions one. I may even find some time to work on it.
Cheers,
Panagiotis
Herve Quiroz
On Mon, Oct 17, 2005 at 04:09:37PM +0300, Achilleus Mantzios wrote:
> Perhaps i missed something,
> but why all that bother with eclipse, when (at least) all the
> java add-ons for it are easily managed by the tool itself?
>
> For possible JNI eclipse plugins (if any) a port definately
> makes sense but for the majority (java) i think the community
> over engineers the case instead of working on more vital issues
> of the operation system.
You are right this is becoming a huge issue while it should probably
not.
The main concern, IMHO, is that the 'java' category could disapear as a
main category (a non-virtual category) some day. There are indeed
several people (including me) who believe that it was a mistake in the
first place and I am starting to think that me should effectively get
rid of it before more and more ports are added into it. Take as an
example the recent add of the java/eclipse-webtools port. We decided
some time ago to avoid adding new ports in the 'java' physicial category
when they are not *stricly* Java support-related (that is, JDK, Sun
official libraries and APIs, and such tools). OTOH I can understand why
Norikatsu just did commit the port in 'java' because all other Eclipse
ports were already there. I believe that moving the ports that do not
rely to core Java support from the 'java' main category would allow
commiters to avoid such practices. That's why I agree with this whole
"eclipse repocopy" concern.
Now, I am probably not well aware of the actual use of each Eclipse
package to be be the right person to decide whether we should have them
all in the same main category or scattered all over the ports tree. But
if I am to give my two cents on the topic, I believe that if we want to
get rid of the "Java exception" (the only language with its own
non-virtual category, no specific PKGNAMEPREFIX while perl, python and
other have one...) we should not produce another exception, namely the
"Eclipse exception". Hence I think we should do just the same as for the
many other "applications with many modules" that exists in the tree
(Emacs is IMHO a good example) and thus I think scattering them is a
fine approach.
To sum up, scatter them or put them in one single place, but please move
them from the 'java' category once the ports tree slush is over. That
will be 24 ports less to move when we decide to get rid of the
non-virtual 'java' category and moreover this will allow new Eclipse
ports to comply with the defined conventions for Java ports.
Herve
Vizion
Wow
That is great
That is what I have been arguing for for three months!!
david
>
>Cheers,
>
>Panagiotis
Herve Quiroz
> >This can be done today, with an eclipse-plugins meta-port, similar to
> >the php5-extensions one. I may even find some time to work on it.
>
> Wow
>
> That is great
>
> That is what I have been arguing for for three months!!
Yes, but you have been arguing for /usr/ports/eclipse and
/usr/ports/eclipse/plugins which are both major changes to ports
framework whereas php5-extensions is just a port as any other in the
*existing* framework. And I remember suggesting something similar with a
plugin support using MASTERDIR months ago.
Anyway, if this is just a matter of having the same as
lang/php5-extensions, I fully agree with the approach. Moreover, I am
glad to see that we have come to agree on some point (although I don't
know yet if people from freebsd-eclipse@ will effectively chose that
particular approach).
Now regarding the new non-virtual category, I think this goes beyond the
scope of the freebsd-java@ team so I'll let others (freebsd-ports@ and
probably portmgr@) deal with this new issue. FWIW, I remember some
earlier discussion regarding the creation of a new category (IIRC it was
about splitting 'net' into 'net-p2p' and such) where hundreds of ports
were concerned and the discussion not only took a long time but as you
can see these new categories never hit the ports tree. So I guess
you'll have to be patient and explain your point in a much humble
fashion than what you did for this eclipse plugin framework discussion.
Herve
Mark Linimon
> have to resort to 'make search' to find emacs tools these days
> because they've been thrown all over the ports system by well-meaning
> but misguided contributors, and I'd hate to see that happen to
> eclipse tools too.
Well, I was completely shocked to find out that 'emacs' is not a virtual
category. This is clearly just a bug and needs to be fixed. This is
especially more shocking since 'elisp', which should be a strict subset,
is a virtual category:
http://www.FreeBSD.org/ports/elisp.html
Related note: as of a few hours ago, I've taken a first whack at what I
feel is another part of this overall problem. The main ports web page at
http://www.FreeBSD.org/ports/ has always just presented the links to the
various ports categories alphabetically in one huge list. IMHO that's
just simply unreadable. What I've done now (with Edwin Groothius' help
to do the actual implementation) is split them up by logical groups.
While completely inadequate for 'true' browsing it is at least one piece
of the puzzle.
Adding 'emacs' and 'eclipse' virtual categories is something further that
we could do quickly, for a fairly low cost, and get an immediate benefit from.
mcl
Vizion
BTW
If you get time would there be any chance you could set up the localized
plugin archive so that it conforms with Eclipse's expectation for plugin
installation.
Up until now, on a multi-user system, each user has to bring plugins into
their individual work directories. This has led to different users
inadvertently working with different plugin versions. One of the reasons I
want to get the /usr/ports/eclipse/ and /usrports/eclipse/plugins hierarchies
working is to have a systenatic method of ensuring devellopers are working
with identical plugin versions. The ports tree system provides an ideal
method of monitoring the plugins.
The other advantage of the meta-port is that we will be immediately able to
bring the remaining 300 plugins into freebsd. This would be a great leap
forward
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>On Tue, Oct 18, 2005 at 07:30:52AM -0700, Vizion wrote:
I just lost it -- for three months I have put up with being polite in
response to knee jerk reactions about "not making exceptions" and repeated
demonstrations of a mindset that does not understand the implications of
framework centric computing.
I remember all the ineffectual battles with system focussed people back in the
early 70's and was horrified that we were unabole to counter the rise of MS
because the **ix community was unable to wrest control of its development
cycle from engineers and determine its future policy by reference to user
requirements.
I see this happening again.
I would argue that the powerful combination of JVM and framework centric
processing will make OS choice dependent upon how easy it is for the user to
control everything via an interface like eclipse.
I would like to see freebsd lead the way
david
>
>Herve
Mark Linimon
> was horrified that we were unable to counter the rise of MS because
> the **ix community was unable to wrest control of its development
> cycle from engineers and determine its future policy by reference
> to user requirements.
If you haven't noticed, almost everyone who provides FreeBSD to you
is a _volunteer_. Most of them are engineers or developers or system
administrators or the like. They work on FreeBSD mostly because they
consider it A Neat Thing; there's no money, and not much glory, in it
otherwise.
If you, personally, want to set up an entity that develops a FreeBSD-
based product with a feature set defined on a completely user-driven
basis (e.g. something like a "Linux distro"), feel free to do so. IMHO
you would be meeting a lot of people's needs. I would even hope that you
could make a solid commercial entity out of it. If it had a good enough
business model, I would probably even send you a resume.
But in the meantime, while we try to _listen_ to what the users want, in
the end of the day what gets _built_ is what any individual contributor
wants to build -- for whatever their own motivations are.
Simply repeating over and over again that the developers are to some
extent "bad guys" for not immediately changing the way that the code is
set up to suit you personally is not going to provide any extra positive
motivation to these individuals.
But I suspect this point is going to be lost on you, because you seem
to want it free, and your way, and right now. To the extent that that's
true, I predict that you are going to continue to be very frustrated and
unhappy with FreeBSD -- or, for that matter, any other community-based
effort.
Let me know if you get that funding together, I honestly think it would
be an interesting project.
mcl
Phil Helms
http://www.dragonflybsd.org/main/
Mark Linimon wrote:
>
> If you, personally, want to set up an entity that develops a FreeBSD-
> based product with a feature set defined on a completely user-driven
> basis (e.g. something like a "Linux distro"), feel free to do so. IMHO
> you would be meeting a lot of people's needs. I would even hope that you
> could make a solid commercial entity out of it. If it had a good enough
> business model, I would probably even send you a resume.
>
--
Phil Helms
phe...@mindspring.com
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>On Tue, Oct 18, 2005 at 09:08:22AM -0700, Vizion wrote:
>> was horrified that we were unable to counter the rise of MS because
>> the **ix community was unable to wrest control of its development
>> cycle from engineers and determine its future policy by reference
>> to user requirements.
>
>If you haven't noticed, almost everyone who provides FreeBSD to you
>is a _volunteer_. Most of them are engineers or developers or system
>administrators or the like. They work on FreeBSD mostly because they
>consider it A Neat Thing; there's no money, and not much glory, in it
>otherwise.
I know that -- from my own experience and contributions to the freebsd ports
system. My view is that the validity of a particular point of view does not
depend upon how much or how little someone has contributed to the community.
Therefore I do not believe my contributions are relevant nor are arguemnts
mande any better or any worse by the quality od contributions in other areas.
I happen to believe that we are both, in this dialogue, making a contribution
to FreeBSD.
>
>If you, personally, want to set up an entity that develops a FreeBSD-
>based product with a feature set defined on a completely user-driven
>basis (e.g. something like a "Linux distro"), feel free to do so. IMHO
>you would be meeting a lot of people's needs. I would even hope that you
>could make a solid commercial entity out of it. If it had a good enough
>business model, I would probably even send you a resume.
This sounds to me like the argument about if you have an argument with this
governemnt you should go amnd live elsewhere.. sorry I do not buy that
argument. I have been a freebsd user and contributor since its early days and
am not in a hurry to go elsewhere.
>
>But in the meantime, while we try to _listen_ to what the users want, in
>the end of the day what gets _built_ is what any individual contributor
>wants to build -- for whatever their own motivations are.
Agreed.. and this is where the dilemna comes in. The issue is do we build for
users or for ourselves. To my mind there is an intelligent middle road.
Something for ourselves and something for the wider commuity. That means
having an eye on the needs of the users of tomorrow.
This debate is to my mind a healthy oner fopr the FreeBSD community I will not
make any apology for pursuing it-- because I believe it FreeBSD needs to
concentrate on becoming more user focus and less technologically focussed.
I aso make no apology for getting mad-- I do regard rule based responses such
as -- we cant make an exception-- as narrow minded BS.. BUt hey that is not a
good idea because {good reason focused on meeting user need} get my full
attention!
>
>Simply repeating over and over again that the developers are to some
>extent "bad guys" for not immediately changing the way that the code is
>set up to suit you personally is not going to provide any extra positive
>motivation to these individuals.
Do not put me there -- I am a developer myself.. My comments are directed not
at developers as a class - but at a mindset of certain developers who, with
the best of intentions, see technology as a self sufficient discipline
rather than seeing technology as a tool to serve the rest of the community.
The former tends to look to the existing system to decide what is best to do
next - the latter look to the needs of the external world.
>
>But I suspect this point is going to be lost on you, because you seem
>to want it free, and your way, and right now.
Please do not put words in my mouth -- I want decisions based upon the merit
of the argument not on the inertia of precedent. So if I need to argue
against the inertia will make no apology for doing so.
>To the extent that that's
>true, I predict that you are going to continue to be very frustrated and
>unhappy with FreeBSD -- or, for that matter, any other community-based
>effort.
Who says I am unhappy with freebsd. after all I use it extensively and am
installing it on another twelve machines during the next year. I find the
community mutually helpful and enjoy it. I do get frustrated at times -- but
frustration is good - you need to realise that my energy comes from a
realization that we need to make good things even better - and not get hung
up on yesterdays ways of doing things
>
>Let me know if you get that funding together, I honestly think it would
>be an interesting project.
Thanks
Panagiotis Astithas
I'm not sure I understand what you are saying here. Eclipse plugins are
stored in the 'features' and 'plugins' subdirectories. They are also
cached in the .eclipse folder in the user's home directory. If a user
somehow ends up with a corrupted cache, there is always the -clean
invocation of eclipse that recreates it. If the problem you encountered
stems from the default permissions on the eclipse directory, you could
always change them to fit your needs (I know I do).
Cheers,
Panagiotis
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>Hi Achilleus,
There is a very practical reason for not scattering.
The '"lets not make an exception" argument misses the point. Can not the
practical needs of users rather than precedent be our guide here? Eclipse and
other emerging framework centric computing environments are essentially
different from traditional application centric computing.
If we try and shoehorn franework centric ports into a ports system which is
designed for application centric computing we are not giving equal weight to
disparate needs.
Framework centric environments are different and need different treatment.
>
>To sum up, scatter them or put them in one single place, but please move
>them from the 'java' category once the ports tree slush is over.
I agree eclipse does not belong in the java category - it, and any other
subsantial framework centric port needs its own category.
>That
>will be 24 ports less to move when we decide to get rid of the
>non-virtual 'java' category and moreover this will allow new Eclipse
>ports to comply with the defined conventions for Java ports.
>
>Herve
>_______________________________________________
>freebs...@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>(To all)
>
>Wes Peters wrote:
>> That's exactly the point I was (and am) trying to argue against. I
>> have to resort to 'make search' to find emacs tools these days because
>> they've been thrown all over the ports system by well-meaning but
>> misguided contributors, and I'd hate to see that happen to eclipse
>> tools too.
>
>As the directory structure imposes Big->Small naming
>on the ports, and this is always going to be inadequate.
>Many ports will have multiple namings and multiple
>ways of indexing that make lots of sense. The directory
>structure gives one indexing and one name only though.
>
>The problem is not where Eclipse or a plugin is located,
>rather, it is that the directory structure cannot support
>anything more complex than the simplest naming schemes.
So what could be more simple than /usr/ports/eclipse?
>
>Moving Eclipse does not change this, only improving
>the search tools can help here. So what is needed
>is something that deals with:
>
> searchports eclipse plugin python
>
>or somesuch.
>
>iang
>
>_______________________________________________
>freebs...@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-java
>To unsubscribe, send any mail to "freebsd-java...@freebsd.org"
Bruce R. Montague
Hi, re large IDE-like things (Eclipse, Emacs) and
the ports tree... FreeBSD's source-centric ports
tree is probably FreeBSD's second-best feature (after
the source-centric system). Over time (decades) the
ports tree might come to be one of the world's great
repositories, or at least repository "index" (isn't
it already? ;). It should make no bones about this.
Two trends relating to the ports tree (an opinion):
* Any really succesful large application, over time
(again, decades) becomes it's own interpretter-
language-IDE-environemnt. Past a certain point,
these things often never go away, they just grow.
In addition to things like Emacs, Eclipse, and even
X (hey, what about the Java Netbeans environment
users?) there are a number of application-oriented
systems: OpenOffice, R, Octave, Grass, maxima, etc..
R (open source version of S stat-pack), Octave (open
source Matlab), grass (open source GIS), maxima (open
source, well, Macsyma). These things, like Eclipse,
can accumulate all sorts of related shims, addons,
and extensions. Some of these are really popular,
world-class, in their category (R), some are relatively
new, but potentially popular (grass), and some are
almost moribund old classics, maybe starting to make
a come-back (maxima). None of these will ever "take
over the world", because they are special-purpose.
But they can be expected to grow and will often
motiviate use of FreeBSD in classic scientific
workstation environments; FreeBSD should strive to
be a preferred platform for those who want to run
these environments, in particular those who want to
easily track the latest releases, run these sorts
of things simultaneously, and access the source.
* I'm not so sure about framework-centric progamming
taking over the world, but other languages besides
C (or at least those supported by the gcc backend)
are finally(?) becoming somewhat common on Unix
systems, perhaps because computers are now so fast
that interpretters are attractive. If a language
is succesful, of course, over time a lot of other
files in the ports tree will become dependent on it.
(Even if framework-centric systems dont turn out to
be a silver bullet, they likely will continue to grow
like everything else.)
The "Ports in virtual categories" section of the
ports tree currently contains mostly categories for
desktops or programming languages. How hard would
it be to support 2 levels of "virtual categories",
in some cases? Can this already be done? Then one
could add a "Java" virtual category and under it
create "Eclipse" and "Netbeans" categories (or
whatever, just for illustration). Anything in the
ports tree that grew to a certain size, in terms of
the number of other ports that were directly related
to it or dependent on it (or likely to be accessed
and installed by someone using it), would be considered
for inclusion somewhere in the virtual ports tree, where
it could all be viewed as "one big ball of stuff".
- bruce
Herve Quiroz
> > Hey, what about materialized virtual categories? A bunch of
> > symlinks, and everyone's happy. Or is that too much for CVS?
> >
> It would probably be too much for CVS to handle, instead someone could
> modify bsd.port.mk to create the virtual category directories and then
> symbolicly link the ports into these categories.
This is probably getting quite off-topic here but I have just coded this
script to implement what you describe. Someone probably already
implemented such thing but I had 10 minutes to spare between two
simulation runs...
Basically you may set PORTSDIR to a specific path (or else the script
uses /usr/ports) and run the script. It will create the directories
related to virtual categories and symlink ports into them.
Herve