[SUGGEST] Reform eclipse and eclipse related ports
Norikatsu Shigemura
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?
java/eclipse -> devel/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 -> devel/eclipse-devel
java/eclipse-emf -> devel/eclipse-emf
java/eclipse-examples -> devel/eclipse-examples
java/eclipse-gef -> graphics/eclipse-gef
java/eclipse-gef-examples -> graphics/eclipse-gef-examples
java/eclipse-langpack -> devel/eclipse-langpack
java/eclipse-log4e -> devel/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 -> devel/eclipse-uml
java/eclipse-v4all -> devel/eclipse-v4all
java/eclipse-vep -> devel/eclipse-vep
java/eclipse-vep-examples -> devel/eclipse-vep-examples
java/eclipse-viplugin -> editors/eclipse-viplugin
java/eclipseme -> devel/eclipseme
java/phpeclipse -> editors/phpeclipse
Wes Peters
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.
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.
--
Where am I, and what am I doing in this handbasket?
Wes Peters
w...@softweyr.com
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
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
Mark Linimon
> 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.
Norikatsu Shigemura wrote:
> On Sat, 15 Oct 2005 09:14:59 +0900 (JST)
> 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
This sounds fine, too.
Cheers,
Panagiotis
Vizion
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
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-
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
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
dialogue on-
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-
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
dialogue on-
Re: [SUGGEST] Reform eclipse and eclipse related ports:
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"
--
Scott Lambert
> 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/ ).
The inodes, man! The inodes!!!!
Sorry, couldn't resist.
<lurk />
--
Scott Lambert KC5MLE Unix SysAdmin
lam...@lambertfam.org
Roman Neuhauser
> On Mon, Oct 17, 2005 at 05:05:18PM -0500, Scot Hetzel wrote:
> > 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/ ).
>
> The inodes, man! The inodes!!!!
Inodes are cheap compared to the time I spend typing (and fixing
typos in) something like
make search name=\^p5- disp=path cat=www | sed '/^$/d'
compared to
ls -d /u<tab>po<tab>/w<tab>/p5-*
Screw inodes, ls is too nice for the basic stuff.
We could stop using the ugly portname prefixes like p5-, pear-
(they just duplicate information contained in CATEGORIES IMO).
Today, you can usually list all ports in such a virtual category
by doing e. g. ls /usr/ports/*/p5-*, with virtual categories on disk
you could also ls /usr/ports/p5. And, since you'll probably be in
/usr/ports already, the final command is comfortably short (how
about ls ecl<tab>?).
Roman Neuhauser
I'm putting this in my .plan, and will eventually work on it unless
someone points me at a past discussion that showed there were major
technical obstacles to this.
I think I could manage inside /usr/ports/Mk:
* create an update-vcats that works in all of portsdir,
portsdir/category and portsdir/category/port
* maintain a list of names of virtual categories in a make variable
* create symlinks in the virtual categories this port lists in
CATEGORIES
* delete symlinks to this port from other virtual categories if any
But I'm quite concerned about the changes needed to make things like
the package building cluster or make index aware of this. It looks
like it would have quite far reaching consequences. Kris?
Kris Kennaway
I don't have time to think about this much, but it seems to me that
keeping all the symlinks up to date requires a time-consuming walk of
the entire ports tree. However, I'm not sure package builds or index
builds need to know anything about this, since they can just ignore
the symlinks (which represent a duplicate path to the same directory)
and proceed as now with how they do things.
Kris
Wes Peters
Thanks for eliding the mud-slinging and getting back on track here
guys. I think a better, more easily searched index to the ports
system is an admirable goal. How it is implemented is a task I
wouldn't presume to dictate to people who know the ports system so
much better than I do.
The ability to easily tab-search through sensible ports categories
does make it much easier to find ports, especially when you have some
idea of what the port name might be. Tools like 'make search' work
well when you don't know what you're looking for all that well, but
are a pretty broad axe to apply to, for instance, finding the eclipse
gui editor (I know it's eclipse-g{something} or eclipse-v{something})
or a specific kdemultimedia codec.
I'm not pointing this out for my use; I'm pretty adept at finding
stuff in ports. I have a lot of co-workers who are experienced
programmers but not necessarily experience FreeBSD'ers and they often
have trouble finding ports even when they (almost) know the name.
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
Mark Linimon
> 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.
What we 'get' is that you have your individual opinion that you have
stated, repeatedly. What you do not 'get' is that simply restating an
opinion does not necessarily make anyone agree with you.
mcl
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
> I'm not pointing this out for my use; I'm pretty adept at finding
> stuff in ports. I have a lot of co-workers who are experienced
> programmers but not necessarily experience FreeBSD'ers and they often
> have trouble finding ports even when they (almost) know the name.
That highlights my point that IMHO we need two different functionalities:
'search' and 'browse'. 'make search' is barely adequate for searching.
We have nothing at all for browsing (unless you count reading an entire
list of ports in hierarchy as 'browsing', which even an old command-line
kind of guy like me thinks is crude).
IMHO these things are better addressed at the application level, not
inside bsd.port.mk itself. See sysutils/portmanager for what I think
is an interesting first step towards that direction.
That's where I think our work should focus, not on directory structure.
mcl
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
Roman Neuhauser
> On Mon, Oct 17, 2005 at 11:39:52PM -0700, Wes Peters wrote:
> > I'm not pointing this out for my use; I'm pretty adept at finding
> > stuff in ports. I have a lot of co-workers who are experienced
> > programmers but not necessarily experience FreeBSD'ers and they often
> > have trouble finding ports even when they (almost) know the name.
>
> That highlights my point that IMHO we need two different functionalities:
> 'search' and 'browse'. 'make search' is barely adequate for searching.
What are you missing from make search? I'll try and add it if it's
within reasonable bounds of complexity.
> We have nothing at all for browsing (unless you count reading an entire
> list of ports in hierarchy as 'browsing', which even an old command-line
> kind of guy like me thinks is crude).
Can you define 'browsing'?
> IMHO these things are better addressed at the application level, not
> inside bsd.port.mk itself. See sysutils/portmanager for what I think
> is an interesting first step towards that direction.
How will the Wes' colleagues find it? You need to be able to find a
port to install it. If a port is required to make sense of the
structure, we need a bootstrap mechanism, like something in the
base. Like, ls.
> That's where I think our work should focus, not on directory structure.
Doesn't ls belong on the application level? It's the simplest tool
that does the job quite fine (use a well configured shell with
explicit support for FreeBSD ports, eg zsh, and you'll never look
back), and you can combine it with other intimately familiar tools
such as sed, awk, make, whatever.
I would certainly prefer if we considered the fs structure to be the
primary interface (and treated it accordingly). I'm weird, I know.
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
> > That highlights my point that IMHO we need two different functionalities:
> > 'search' and 'browse'. 'make search' is barely adequate for searching.
>
> What are you missing from make search? I'll try and add it if it's
> within reasonable bounds of complexity.
e.g. searching when you don't know the exact spelling of the name.
It's the "dictionary problem" -- how do you find the meaning of a word
when you're not sure what the word is?
> > We have nothing at all for browsing (unless you count reading an entire
> > list of ports in hierarchy as 'browsing', which even an old command-line
> > kind of guy like me thinks is crude).
>
> Can you define 'browsing'?
"show me the ports that have something to do with the Internet"; "show
me a list of plugins that work with Apache2".
> How will the Wes' colleagues find it? You need to be able to find
> a port to install it. If a port is required to make sense of the
> structure, we need a bootstrap mechanism, like something in the
> base. Like, ls.
Don't be silly. Neither portupgrade nor cvsup are in base. People
pkg_install them and then they're good to go. ls is _not_, by any
stretch of the imagination, an adequate tool unless you already have
a pretty good idea of what it is you're looking for.
I really do not believe that anything with a UI belongs in base, and
I believe that 'search' and 'browse', to be useful to the largest number
of people, need to be UI-based; whether that's as applications, or from
web pages, or more likely, both.
> I would certainly prefer if we considered the fs structure to be the
> primary interface (and treated it accordingly). I'm weird, I know.
It's always going to be the 'primary' interface but if we don't build
tools on top of it, it's simply going to limit the ports tree's usefulness
to people who aren't as hardcore as you or I are. fwiw, I rely extensively
on a little script that I wrote that greps things out of the contents of
Makefiles. I am familiar with these kinds of tools.
But, I mean, honestly, I think I can state without much fear of
contradiction that I have as good a working knowledge of what's in the
ports tree as anyone. Even so, the other day I went looking to see if
there was any port specifically geared to synchronizing file systems on
two peer machines (rather than, e.g., geared to just backing up a file
system). It was really painful to do that, and it shouldn't have been.
None of the existing tools are even vaguely adequate for that.
mcl
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
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>On Mon, Oct 17, 2005 at 08:44:01AM -0700, Vizion wrote:
Agreed - so how can I invite those who do not agree with me to at least
appreciate there is another way of looking at things?
But what would be appreciated would be for responses that do not carry with
them comments such as "we cannot make an exception" .
Is there not an old old scientific guideline, for testing a hypothesis, which
runs on the lines of "Create an exception to test the validity of the rule".
The rule being tested seem to fit into two categories.
I. We cannot make an exception - if that were true no one would ever do
anything different for the first time -- Is there any reason why a serious
thinker should not treat such a response as an unthinking knee jerk reaction?
Perhaps what is meant by that remark is hold on - there may be some work
involved.. which then invites a cost benefit analysis..but that did not
happen.
The second is that eclipse is no different from other applications in the
ports tree and therefore should not be treated differently. You are right I
have repeated the argument as to WHY it and other framework centric
applications are different. I argue that because they are different and they
do therefore test the assumptions that lie behind categorization by
application type.
The question to my mind is how do we adapt a valuable tool, the FreeBSD ports
system, to deal with a computing phenomenon that was not around when its
structure was devised during a time when all computer programs were
applications.
The simple solution is to give eclipse its own category.. to treat an
exception as an exception. Can we not acknowledge it is different. Is there
any reason why we cannot adapt to the difference?
You chide me for repeating an argument while I ask why the need for a seperate
category is , without any logical justification, just as frequently presented
as a challenge to precedent which has to be defended against at all costs,
rather than opportunity for the future.
I at least do try to substantiate my arguments against opposing view points..
Unfortunately I have yet to hear any credible argument supporting the
genralized notion "we cannot make exceptions" or indeed any argument which
supports the notion that an exception free world is in any way desirable!
david
>
>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"
--
Roman Neuhauser
> On Tue, Oct 18, 2005 at 06:07:25PM +0200, Roman Neuhauser wrote:
> > > That highlights my point that IMHO we need two different functionalities:
> > > 'search' and 'browse'. 'make search' is barely adequate for searching.
> >
> > What are you missing from make search? I'll try and add it if it's
> > within reasonable bounds of complexity.
>
> e.g. searching when you don't know the exact spelling of the name.
Also, another variable, e. g. KEYWORDS, could be used.
> > > We have nothing at all for browsing (unless you count reading an entire
> > > list of ports in hierarchy as 'browsing', which even an old command-line
> > > kind of guy like me thinks is crude).
> >
> > Can you define 'browsing'?
>
> "show me the ports that have something to do with the Internet";
What are you missing from make search cat=net ? (I'm not suggesting
you don't have valid complaints, I'd like to learn about them.)
> "show me a list of plugins that work with Apache2".
Create a virtual category, apache_mod, and then:
make search cat=apache_mod
Go a step further, use materialized virtual categories, and do
ls apache_mod
If you think this wouldn't fly, I'd also like to hear the reasoning.
> > How will the Wes' colleagues find it? You need to be able to find
> > a port to install it. If a port is required to make sense of the
> > structure, we need a bootstrap mechanism, like something in the
> > base. Like, ls.
>
> Don't be silly.
I don't think I am. I'm pointing out a chicken-and-egg condition
present in your proposal.
> Neither portupgrade nor cvsup are in base. People pkg_install them
> and then they're good to go.
Neither tries to facilitate the browsing or searching of the
collection, and I consider their being part of the problem they try
to solve their weakest spot.
> ls is _not_, by any stretch of the imagination, an adequate tool
> unless you already have a pretty good idea of what it is you're
> looking for.
Same applies to Google, or basically any search interface, or,
closer to the topic, to FreshPorts, which I used about thrice in my
life, BTW.
make search is not The Final Solution, of course, but it can be made
better. Feel free to mail me any suggestions you have.
> I really do not believe that anything with a UI belongs in base, and
> I believe that 'search' and 'browse', to be useful to the largest number
> of people, need to be UI-based; whether that's as applications, or from
> web pages, or more likely, both.
Note: The shell is also a User Interface, but I understand you mean
a Graphical User Interface, or more precisely (because libdialog(3)
is a GUI toolkit), GTK, QT, and the likes.
I agree with what you say.
I've learned over the last 15 years that the most comfortable UI for
the majority of people is a single OK button in the middle of the
screen. I'm fine with that unless someone tries to shove it down
*my* throat.
In compliance with your assessment that FreeBSD is put together by
different people scratching their different needs, I'm doing myself
a favor by contributing the tools that I want to see in the
operating system. (I'm probably one of three people who use [the
extended capabilities of] make search, which IMO proves both your
and mine points.) Unless, or until, someone tries to discourage
improvements to the interface they dislike, everybody can be happy.
> > I would certainly prefer if we considered the fs structure to be the
> > primary interface (and treated it accordingly). I'm weird, I know.
>
> It's always going to be the 'primary' interface but if we don't build
> tools on top of it, it's simply going to limit the ports tree's usefulness
> to people who aren't as hardcore as you or I are.
That's in agreement with what the angry guy pushes: don't let the
rules of yesterday limit the ways you use it today. I don't mind
you spending time writing a web interface (which I won't use),
please don't mind me extending the ways make or ls can be used.
> But, I mean, honestly, I think I can state without much fear of
> contradiction that I have as good a working knowledge of what's in the
> ports tree as anyone. Even so, the other day I went looking to see if
> there was any port specifically geared to synchronizing file systems on
> two peer machines (rather than, e.g., geared to just backing up a file
> system). It was really painful to do that, and it shouldn't have been.
> None of the existing tools are even vaguely adequate for that.
The last two paragraphs seem to back the need to extend the basic
concepts. If we stop thinking in terms of "real" vs "virtual"
categories, and represent membership in multiple categories in terms
of symlinks, we can greatly improve the usability by merely doubling
the number of categories. If we can have
cnt path
11 /usr/ports/hebrew
13 /usr/ports/accessibility
13 /usr/ports/arabic
13 /usr/ports/ukrainian
14 /usr/ports/hungarian
16 /usr/ports/portuguese
19 /usr/ports/mbone
19 /usr/ports/x11-servers
21 /usr/ports/polish
21 /usr/ports/vietnamese
25 /usr/ports/french
then there's surely room for
24 /usr/ports/eclipse
And, 1620 /usr/ports/devel could use a close look at.
Mark Linimon
> > > What are you missing from make search? I'll try and add it if it's
> > > within reasonable bounds of complexity.
> >
> > e.g. searching when you don't know the exact spelling of the name.
>
> Would optional use of double metaphone or another algorithm help?
> Also, another variable, e. g. KEYWORDS, could be used.
Please feel free. I just feel uneasy about having things like that
encoded in Makefiles. I would rather see separate tools which 'make
search' could then invoke -- but then, so could any kind of web-based app.
(The old Unix philosophy of 'small tools in combination').
IMHO we have too much monolithic sh/sed/awk/perl magic in the make-framework
as it is but that's an axe I will grind in a different venue.
> > "show me the ports that have something to do with the Internet";
>
> What are you missing from make search cat=net ? (I'm not suggesting
> you don't have valid complaints, I'd like to learn about them.)
Well, there _are_ a few Internet-related ports in net-mgmt, wwww, ...
> > "show me a list of plugins that work with Apache2".
>
> Create a virtual category, apache_mod, and then:
>
> make search cat=apache_mod
>
> Go a step further, use materialized virtual categories, and do
>
> ls apache_mod
>
> If you think this wouldn't fly, I'd also like to hear the reasoning.
Because now you have to create a virtual category for anything that
anyone could possibly think to search on. Creating some kind of tag-based
system would be better. Then you get people thinking about the tags
as meta-information and then whatever underlying directory structure
becomes an implementation detail.
> > > How will the Wes' colleagues find it? You need to be able to find
> > > a port to install it. If a port is required to make sense of the
> > > structure, we need a bootstrap mechanism, like something in the
> > > base. Like, ls.
> >
> > Don't be silly.
>
> I don't think I am. I'm pointing out a chicken-and-egg condition
> present in your proposal.
I don't think there is any such thing. People install portugprade and
cvsup without searching for them. They, and other, tools are well-known.
Many more ports (in fact the majority) are not. So if you create some
kind of port-browser tool like portmanager, people can still install that.
The documenation about the port system can (and should) document the
management tools, outside of the need to run 'make search' to look
for them. Or perhaps someone(TM) could come up with meta-port that
would pull in all the interesting ports management tools -- one meta-
port for users, one meta-port for developers. How would that sound?
(Note: this is a trick question.)
> > Neither portupgrade nor cvsup are in base. People pkg_install them
> > and then they're good to go.
>
> Neither tries to facilitate the browsing or searching of the
> collection, and I consider their being part of the problem they try
> to solve their weakest spot.
You're entitled to your opinion.
> > ls is _not_, by any stretch of the imagination, an adequate tool
> > unless you already have a pretty good idea of what it is you're
> > looking for.
>
> Same applies to Google, or basically any search interface, or,
> closer to the topic, to FreshPorts, which I used about thrice in my
> life, BTW.
Well, if you don't think Google is an easier interface to use for vague
queries than 'make search' or 'ls', by all means, stick to it. My own
opinion is that you're going to be in a minority but I'm not going to
spend any more time convincing you otherwise.
> I've learned over the last 15 years that the most comfortable UI for
> the majority of people is a single OK button in the middle of the
> screen. I'm fine with that unless someone tries to shove it down
> *my* throat.
I never said we'd get rid of 'make search'. What I said is that I believe
is that for a large group of people it is not going to meet their needs.
I don't know where you came up with the idea that I was discouraging its
use. I just don't think it adequately solves the problem. Your Mileage
Apparently Varies.
[mentions language categories]
> then there's surely room for
>
> 24 /usr/ports/eclipse
>
> And, 1620 /usr/ports/devel could use a close look at.
The problem is: how do you present the information about categories?
If we let every logical group of 24 ports have its own category*, and
eliding for sake of this discussion whether it is physical or virtual,
now you have up to 13666/24=569 categories. Presenting a list of more
than a couple hundred of _anything_ is just useless, as you can see by
trying to look through the devel/ports (no matter whatever mechanism you
choose). If you break devel/ into 1620/24=67 categories you haven't
solved any real problem; you've instead moved the problem up one level
and spent a great deal of developer time to do it.
Now, instead of all this email debate, a few days ago I talked Edwin
Groothius into implementing a test idea about how to break up the
existing category list on http://www.FreeBSD.org/ports/ into logical
groups. It's inadequate but a) it's better than the flat space and b)
it's actual code rather than just talk. I will note that there has
been _zero_ feedback on this change, pro or con. IMHO it's a little,
tiny, step towards exploring ideas about how to display this information.
And frankly at this point I'd rather try to continue to prototype
different approaches than spend any more time on this discussion.
mcl
* which many people want to do, from reasons ranging from valid to IMHO
mere ego-boosting
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"
Mario Hoerich
> On Wed, Oct 19, 2005 at 11:40:18PM +0200, Roman Neuhauser wrote:
[ Locating ports when you don't know the spelling ]
> > Also, another variable, e. g. KEYWORDS, could be used.
Personally, I doubt this'd do much good. With generic keywords
(like "mp3" or "video") a search yields too many hits rather fast,
whereas people are quite likely to outright miss more specific terms.
Besides, every port maintainer probably has his/her very own idea
how to properly set KEYWORDS, so that i.e. "mp3 player" hits
amaroK and juk, but misses xmms. Synchronizing this sure seems
like a can of worms to me.
[ "show me the ports that have something to do with the Internet" ]
> >
> > What are you missing from make search cat=net ? (I'm not suggesting
> > you don't have valid complaints, I'd like to learn about them.)
A man-page. Or at least a proper help.
| $ make search
| The search target requires a keyword parameter or name parameter,
| e.g.: "make search key=somekeyword"
| or "make search name=somekeyword"
doesn't exactly tell me about cat= or the difference between
key= and name=.
Other than that: a less non-standard syntax. I'd highly favor
portsearch [-c<cat>] (-k<key> | <name>).
> Well, there _are_ a few Internet-related ports in net-mgmt, wwww, ...
This applies to quite a lot of ports, I think. See xmms, for example.
It took me quite a while to realize the 54 xmms-$foo ports in audio
didn't include xmms itself. I finally located it via LIB_DEPENDS.
> > I don't think I am. I'm pointing out a chicken-and-egg condition
> > present in your proposal.
>
> I don't think there is any such thing. People install portugprade and
> cvsup without searching for them. They, and other, tools are well-known.
> Many more ports (in fact the majority) are not. So if you create some
> kind of port-browser tool like portmanager, people can still install that.
I'd favor a set of tools, a library and an ncurses frontend *in base*.
The current set
* portmanager
* port{up,down}grade
* portversion
* portsnap
* portsman
* pkg_{delete,remove}
* pkg_{add,install}
* pkg_info
* pkg_{cut,rm}leaves
* cvsup (what happened to csup btw?)
* make search
* make [fetch]index
isn't exactly consistent in either naming or behavior and there's
probably quite a couple of reinvented wheels inside. The ports
collection being one of the most visible features of FreeBSD, I
think this is bad.
Oh, I'd like my bikeshed blue with dark green stripes, btw.
> Now, instead of all this email debate, a few days ago I talked Edwin
> Groothius into implementing a test idea about how to break up the
> existing category list on http://www.FreeBSD.org/ports/ into logical
> groups. It's inadequate but a) it's better than the flat space and b)
> it's actual code rather than just talk. I will note that there has
> been _zero_ feedback on this change, pro or con.
The thought is actually quite nice, but the logical groups aren't
disjoint on any count. The "ports for end-users" contain plenty
of ports for devs (e.g. audio/p5-Filesys-Virtual-DAAP), whereas
many actual end-user ports (e.g. Firefox) are elsewhere.
So essentially, it doesn't really help (me).
If you're serious about improving the browseability, then the only
real way _I_ can see is to separate applications from libraries and
$lang-ports. Fwiw, I'm aware this implies literally thousands of
repocopys, and that I'm most likely not the one doing them or
dealing with the fallout. It might still be worth consideration
as a long term plan, though.
Regards,
Mario
Michael C. Shultz
My .02 cents worth - - - Would the ports system handle adding another level to
its directory structure? A quick way to organize some of the 1000+ port
categories?
-Mike
Mark Linimon
> My .02 cents worth - - - Would the ports system handle adding another
> level to its directory structure?
This is the biggest FAQ about the ports collection and the answer is
always going to be the same: NO. We have nearly ten thousand lines of
automated tools which have the two-level assumption hardwired into them.
Fixing this would require many, many, hundreds of hours to do the necessary
rewriting and regression testing.
Reading back through the mailing lists would have shown you this.
mcl
Mark Linimon
> I'd favor a set of tools, a library and an ncurses frontend *in base*.
> The current set
>
As stated many times in the past, cvsup is not going into base due to
its dependency on modula-3.
FreeBSD went through a great deal of pain and trouble to wean itself off
having perl in the base system, for reasons that have been adequately
documented and argued over. We are not going to go backwards.
In any case modula-3 does not even work on all of our architectures.
As for your other ports in this list, there is a meta-port that will
install them all, you know.
> The thought is actually quite nice, but the logical groups aren't
> disjoint on any count. The "ports for end-users" contain plenty
> of ports for devs (e.g. audio/p5-Filesys-Virtual-DAAP), whereas
> many actual end-user ports (e.g. Firefox) are elsewhere.
True, but we're talking about what can be done in hours instead of in
weeks or months, here.
mcl
Michael C. Shultz
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?
-Mike
Mark Linimon
> 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.
You will be submitting thousands, if not tens of thousands, of lines of
patches to do so, invoving sh, awk, sed, perl, python, and SQL -- that I
know of. There are probably others.
Now: I am not going to discuss this issue any further until I see those
patches.
People, you just have No Idea how much work you are talking about here,
just to fiddle around with organizing ports into directories on a physical
disk, which I will continue to restate my opinion until I am blue in the
face that is the wrong problem to solve _anyway_.
The _right_ problems to solve are searching and browsing. If you solve
those problems correctly, the physical layout on disk becomes hidden as
an implementation detail and no one but hardcore ports developers ever
has to think about it again.
And you don't have to regression test thousands of lines of patches to
do so.
This is at least the 20th time this particular idea has been floated.
It hasn't gotten any better the last 19 times. Please go back and read
the archives. I'm done discussing it.
mcl
Michael C. Shultz
You seem to have your feet well planted on this issue, probably for good
reason.
What about a /usr/ports2 multilevel directory with softlinks to ports
in /usr/ports??? I fiddle with this a bit, if it looks good I'll put
something together as a port for you to take a look at.
-Mike
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>On Fri, Oct 21, 2005 at 02:54:41PM -0700, Michael C. Shultz wrote:
Maybe the hard lesson from this is that before coding any future project for
freebsd the proposed structure and a block diagram could be:
1. passed to a systems engineer to advise on the structure. That should avoid
"hard-wired" design limitations in future projects.
2. Placed on the freebsd.org website for comunity input.
Given that this is such an obvious design flaw why is their such reluctance to
mitigate its effects by introducing additional categories!
david
Roman Neuhauser
> On Wed, Oct 19, 2005 at 11:40:18PM +0200, Roman Neuhauser wrote:
> > > > What are you missing from make search? I'll try and add it if it's
> > > > within reasonable bounds of complexity.
> > >
> > > e.g. searching when you don't know the exact spelling of the name.
> >
> > Would optional use of double metaphone or another algorithm help?
> > Also, another variable, e. g. KEYWORDS, could be used.
>
> Please feel free. I just feel uneasy about having things like that
> encoded in Makefiles. I would rather see separate tools which 'make
> search' could then invoke -- but then, so could any kind of web-based app.
> (The old Unix philosophy of 'small tools in combination').
> IMHO we have too much monolithic sh/sed/awk/perl magic in the make-framework
> as it is but that's an axe I will grind in a different venue.
I agree with you here. make search was a bit tough to debug, and I
plan to move the code to a separate script that will be run by make
search.
> > > "show me the ports that have something to do with the Internet";
> >
> > What are you missing from make search cat=net ? (I'm not suggesting
> > you don't have valid complaints, I'd like to learn about them.)
>
> Well, there _are_ a few Internet-related ports in net-mgmt, wwww, ...
So, would (virtual) membership in net (or inet) help here?
> > > "show me a list of plugins that work with Apache2".
> >
> > Create a virtual category, apache_mod, and then:
> >
> > make search cat=apache_mod
> >
> > Go a step further, use materialized virtual categories, and do
> >
> > ls apache_mod
> >
> > If you think this wouldn't fly, I'd also like to hear the reasoning.
>
> Because now you have to create a virtual category for anything that
> anyone could possibly think to search on. Creating some kind of tag-based
> system would be better.
But then you'll have to create and use every tag anyone could
possibly think to search on. Otherwise, the tag system would have
the same problem as the vcat system.
> Then you get people thinking about the tags as meta-information and
> then whatever underlying directory structure becomes an implementation
> detail.
FMPOV youre just proposing to use a different transport for the
information the category directory names and contents carry now. If
the filesystem were used to represent membership in additional
categories, the directory structure could carry that
metainformation, and we would achieve comparable results with
fewer parts.
Besides, this is exactly the thing I fear will happen: that someone
else will claim my interface their implementation detail, and I'll be
denied my favorite interface.
> > > > How will the Wes' colleagues find it? You need to be able to find
> > > > a port to install it. If a port is required to make sense of the
> > > > structure, we need a bootstrap mechanism, like something in the
> > > > base. Like, ls.
> > >
> > > Don't be silly.
> >
> > I don't think I am. I'm pointing out a chicken-and-egg condition
> > present in your proposal.
>
> I don't think there is any such thing. People install portugprade and
> cvsup without searching for them. They, and other, tools are well-known.
> Many more ports (in fact the majority) are not. So if you create some
> kind of port-browser tool like portmanager, people can still install that.
You said above that the underlying directory structure could become
an implementation detail. If you stop thinking of the directory
layout as a major human interface, it'll cease functioning in that
regard quite quickly. See /etc/sysconfig on an RHEL system.
The user friendliness (FMPOV) of /usr/ports lies in the fact that
it's all easily accessible to humans. Makefiles are quite easy to
read and use, and all information is stored in human accessible
representations in text files. This is a huge plus of the ports, and
should be kept in mind.
> The documenation about the port system can (and should) document the
> management tools, outside of the need to run 'make search' to look
> for them. Or perhaps someone(TM) could come up with meta-port that
> would pull in all the interesting ports management tools -- one meta-
> port for users, one meta-port for developers. How would that sound?
>
> (Note: this is a trick question.)
Two tricks that I can see:
- *what* are "all the interesting tools"? IOW, emacs or vim for
developers, kportman or gportman for users?
- how would the users find the metaports?
> > > ls is _not_, by any stretch of the imagination, an adequate tool
> > > unless you already have a pretty good idea of what it is you're
> > > looking for.
> >
> > Same applies to Google, or basically any search interface, or,
> > closer to the topic, to FreshPorts, which I used about thrice in my
> > life, BTW.
>
> Well, if you don't think Google is an easier interface to use for vague
> queries than 'make search' or 'ls', by all means, stick to it. My own
> opinion is that you're going to be in a minority but I'm not going to
> spend any more time convincing you otherwise.
You're mixing two problems here, and completely missed my point.
The interface: web client is a very fine tool for that because
you'll use it to manipulate the result set. The idea of installing
software by clicking on links in a web page isn't that comfortable.
The search: besides being smarter than 30 lines of awk about the
data it processes, the data Google has is completely different, much
richer, and quite self-describing. An average article about
std::vectors is much longer than any COMMENT, and you won't get much
better results even with a 3d graphical virtual reality browser.
And, my point was that Google isn't mostly used to find "the" page,
I rather want "a" page on std::vectors. If you don't know that the
port you're looking for is a CORBA ORB, you're probably screwed with
or without a web interface, but you can already do ls -d */*orb* if
you do.
> > I've learned over the last 15 years that the most comfortable UI for
> > the majority of people is a single OK button in the middle of the
> > screen. I'm fine with that unless someone tries to shove it down
> > *my* throat.
>
> I never said we'd get rid of 'make search'. What I said is that I believe
> is that for a large group of people it is not going to meet their needs.
> I don't know where you came up with the idea that I was discouraging its
> use. I just don't think it adequately solves the problem. Your Mileage
> Apparently Varies.
If the directory structure becomes, and is treated as an
implementation detail, it will sooner or later lose its current
accessibility. I like to ls-and-see around ports.
> [mentions language categories]
That was the top of
for c in /usr/ports/[a-z]*(/); do echo "$(ls $c | wc -l) $c"; done | sort -n
IOW, I was pointing at the smallest categories, whether they were
language or other was unimportant.
> > then there's surely room for
> >
> > 24 /usr/ports/eclipse
> >
> > And, 1620 /usr/ports/devel could use a close look at.
>
> The problem is: how do you present the information about categories?
Can you try again? I don't understand the question.
> If we let every logical group of 24 ports have its own category*, and
> eliding for sake of this discussion whether it is physical or virtual,
> now you have up to 13666/24=569 categories. Presenting a list of more
> than a couple hundred of _anything_ is just useless, as you can see by
> trying to look through the devel/ports (no matter whatever mechanism you
> choose). If you break devel/ into 1620/24=67 categories you haven't
> solved any real problem; you've instead moved the problem up one level
> and spent a great deal of developer time to do it.
Well, I do think that splitting a heap of 1620 ports into 67 chunks,
each of manageable size, would help. It would add new, finergrained
ways of looking those 1620 ports that aren't organized any further.
Also, the average number of ports in a category is unknown, but even
if I accept your guesstimate of 569 categories, the number is still
three times smaller than the 1620 in devel, so it looks like a win.
Thanks, assured me that it is a worthwile project to set on.
> Now, instead of all this email debate, a few days ago I talked Edwin
> Groothius into implementing a test idea about how to break up the
> existing category list on http://www.FreeBSD.org/ports/ into logical
> groups. It's inadequate but a) it's better than the flat space and b)
> it's actual code rather than just talk. I will note that there has
> been _zero_ feedback on this change, pro or con.
I haven't seen that page since a few years. Here's my .2 if you're
interested:
The dictionary in top page adds information which isn't in the
ports, and that's the added value that makes finding something
without knowing the right words possible: it's described in more
ways. It's not the transport that makes it better, it's the metadata
it adds. If the information that is in the web page was in
/usr/ports/README (possibly with reST or wiki format for easy
conversion to html), it could be used with or without a browser or
an internet connection.
The search form is inferior to make search, it provides no way to
enter specific queries (all you have is All / Package name /
Description) leading to false positives and negatives in results.
Doing this well on the web is hard, because static forms have static
complexity, and eg the complex search form in bugzilla doesn't get
any smaller whan you don't use all its knobs. On the command line,
the complexity of the interface grows with the complexity of your
query.
The conversion to html makes viewing pkg-descr files somewhat easier
(with urls made into links, which is nice), but getting at the
Makefile and other files in the port directory is somewhat harder.
> IMHO it's a little, tiny, step towards exploring ideas about how to
> display this information. And frankly at this point I'd rather try to
> continue to prototype different approaches than spend any more time on
> this discussion.
Ok, bye.
Roman Neuhauser
> 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.
Interfaces sometimes change for the better, just update your code
and be done with it.
Note that I'm not advocating doing the repocopies because that would
royally screw the repository history, and that's just not worth it.
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
># lin...@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?
Good point
I know my opinion might be regarded as ecentric but, as I see it, the
community is spending far too much od its developmental resopurces on
advancing the operating system and far too little on bringing user interfaces
and convenience up to date.
I see it as time to slow down on OS development and really focus on bringing
the operating system management to a level that accords with comparable
modern day standards.
David
>>
>> 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.
Agreed -
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>On Friday 21 October 2005 15:39, you wrote:
>> 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.
>>
>> You will be submitting thousands, if not tens of thousands, of lines of
>> patches to do so, invoving sh, awk, sed, perl, python, and SQL -- that I
>> know of. There are probably others.
>>
>> Now: I am not going to discuss this issue any further until I see those
>> patches.
>>
>> People, you just have No Idea how much work you are talking about here,
>> just to fiddle around with organizing ports into directories on a physical
>> disk, which I will continue to restate my opinion until I am blue in the
>> face that is the wrong problem to solve _anyway_.
>>
>> The _right_ problems to solve are searching and browsing. If you solve
>> those problems correctly, the physical layout on disk becomes hidden as
>> an implementation detail and no one but hardcore ports developers ever
>> has to think about it again.
In addition to searching and browsing there are problems associated with the
physival organization of files on local systems as well as on the freebsd
server systems. This issue is not addressed by fiddling with just the search
and browsing issue.
With framework centric computing one needs the ports system to have a
hierarchy that matches local needs as well as server needs.
As a temporary measure that could be done by making more categories available
without the currenty hassle. e.g. /usr/ports/java and /usr/ports/eclipse
while more long terms redesign of of outfate two tier ports system can be
implemented
My two pennorth
david
>>
>> And you don't have to regression test thousands of lines of patches to
>> do so.
>>
>> This is at least the 20th time this particular idea has been floated.
>> It hasn't gotten any better the last 19 times. Please go back and read
>> the archives. I'm done discussing it.
>>
>> mcl
>
>You seem to have your feet well planted on this issue, probably for good
>reason.
>
>What about a /usr/ports2 multilevel directory with softlinks to ports
>in /usr/ports??? I fiddle with this a bit, if it looks good I'll put
>something together as a port for you to take a look at.
>
>-Mike
>
>
>
>
>
>
>
>_______________________________________________
>freebs...@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
Norikatsu Shigemura
Vizion <viz...@vizion.occoxmail.com> wrote:
> On Friday 21 October 2005 16:59, the author Roman Neuhauser contributed to
> the dialogue on-
> Re: [SUGGEST] Reform eclipse and eclipse related ports:
> ># lin...@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?
> Good point
> I know my opinion might be regarded as ecentric but, as I see it, the
> community is spending far too much od its developmental resopurces on
> advancing the operating system and far too little on bringing user interfaces
> and convenience up to date.
> I see it as time to slow down on OS development and really focus on bringing
> the operating system management to a level that accords with comparable
> modern day standards.
> >> 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.
> Agreed -
Hum.. The eclipse repocopy discussion became new ports system
discussion. Next time, please implement ports2/eclipse or
ports/eclise. So I'll repocopy from */eclipse-* to eclipse/, too.
BTW as soon as possible;-), I'll send-pr my 2nd repocopy plan
(java/eclipse -> editors/eclipse), and repocopy these.
Michael C. Shultz
> On Friday 21 October 2005 16:59, the author Roman Neuhauser contributed to
> the dialogue on-
>
> Re: [SUGGEST] Reform eclipse and eclipse related ports:
> ># lin...@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?
>
> Good point
>
> I know my opinion might be regarded as ecentric but, as I see it, the
> community is spending far too much od its developmental resopurces on
> advancing the operating system and far too little on bringing user
> interfaces and convenience up to date.
>
> I see it as time to slow down on OS development and really focus on
> bringing the operating system management to a level that accords with
> comparable modern day standards.
>
to race for higher version numbers while problems remain with previous
versions. As far as the ports system goes though, to date FreeBSD is way
ahead of every other OS I've looked at IMO, of corse that is a poor excuse to
stagnate.
-Mike
Vizion
I agree with what you say. It is because the ports system is so good that I
want:
a) o see it used to the full despite its limitations (everything can be mafe
better and its easier to make better things excelllent that things that have
been done less well!! :-)
b) Because the ports system provides a sound starting point for a thoughtfully
designed system wide management GUI built either by using mysql/apache/php or
through using something like eclipse.
c) building a modern system management interface needs OS development to slow
down while user interface systems catch up .. then we have a basis to really
go forward
My two pennorth
david
>
>-Mike
>
>_______________________________________________
>freebs...@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>To unsubscribe, send any mail to "freebsd-port...@freebsd.org"
--
Mark Linimon
> 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?
If you don't understand the extent of that code, I can see how easy it
might be for you to assume that it's easy to work with.
Please see ports/Tools/portbuild. Also you will be rewriting the
marcusom tinderbox at tinderbox.marcuscom.com as well. I do not know
under what license the FreshPorts code is.
> portsmon is your software, and keeping it hostage to changes in
> ports is IMO unethical.
What I am _implying_ is that a lot of work has to be done to make it
work, and that I _personally_ am not going to make it a priority to
rewrite it based on someone's pet blue-sky idea.
The fact that you would charge someone like me who has put literally
HUNDREDS of hours into that system -- for his own personal internal
movtivation, there are no extrinsic rewards -- with being unethical is
a complete and total outrage. As far as I am concerned this gives me
complete permission to just ignore anything you have to say after this
point. You have apparently missed a key underlying principle of this
project: that it's a _volunteer_ project and you cannot _compel_ a
volunteer to go work on anything that they are not personally interested
in working on.
If you don't like this, the code is available under BSDL. Grab a
copy, install it yourself, rewrite it, run it, and claim your solution
obsoletes mine. That's the "BSD way". But if you insist that I do all
that just on your whim, you're going to be out of luck. (And, along the
way, you might find out how much work is already going into maintaining
it -- work, like much of what goes into the ports collection, that goes
on, unheralded, behind the scenes -- unlike all the bikeshedding like
this that goes on in public and what people seem so impressed by,
despite the fact that, in general, nothing actually gets accomplished).
I simply don't have the free time to rewrite it _and_ work on all the
other priorities to which I have currently, and in the past, put so much
time into on this project -- ones, as far as I am concerned, will have
a much higher impact on the usability of the system.
Before you get all the above done, I might even be able to _prototype_
some kind of better search mechanism and solve the more useful part of
the problem. To me, it would clearly take far less time to do so.
However, as far as I'm concerned, you've destroyed your own credibility
with what I've quoted above, so I'm simply going to go back to _doing_
work rather than arguing with you, which is clearly going to accomplish
exactly nothing. It's not even worth my time to ask for an apology for
it, either, although in my own mind I'm due one. I just have better
things to do.
mcl
Vizion
the dialogue on-
Re: [SUGGEST] Reform eclipse and eclipse related ports:
># lin...@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
Vizion
Re: [SUGGEST] Reform eclipse and eclipse related ports:
>On Sat, Oct 22, 2005 at 01:59:50AM +0200, Roman Neuhauser wrote:
>> 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?
>
>If you don't understand the extent of that code, I can see how easy it
>might be for you to assume that it's easy to work with.
>
>Please see ports/Tools/portbuild. Also you will be rewriting the
>marcusom tinderbox at tinderbox.marcuscom.com as well. I do not know
>under what license the FreshPorts code is.
>
>> portsmon is your software, and keeping it hostage to changes in
>> ports is IMO unethical.
As I have pointed out elsewhere I think Mark's accusation is both unfair and
totally unwarranted - it only diverts attentions from some good point that he
makes.
>
>What I am _implying_ is that a lot of work has to be done to make it
>work,
II think everyone knows that
>and that I _personally_ am not going to make it a priority to
>rewrite it based on someone's pet blue-sky idea.
OK but I do not think it helps not to recognize that there are difficulties
with the existing system and maybe if you appeared more accepting of the
critics of the system and less inclined to personalize the issue maybe those
of us who see things differently to you would see you as a potential ally
rather than an obstacle to change.
>
>The fact that you would charge someone like me who has put literally
>HUNDREDS of hours into that system -- for his own personal internal
>movtivation, there are no extrinsic rewards -- with being unethical is
>a complete and total outrage. As far as I am concerned this gives me
>complete permission to just ignore anything you have to say after this
>point. You have apparently missed a key underlying principle of this
>project: that it's a _volunteer_ project and you cannot _compel_ a
>volunteer to go work on anything that they are not personally interested
>in working on.
I do not think anyone has suggested you should do that - but I hear that
wondering if that is what they think is painful to you.
>
>If you don't like this, the code is available under BSDL. Grab a
>copy, install it yourself, rewrite it, run it, and claim your solution
>obsoletes mine. That's the "BSD way". But if you insist that I do all
>that just on your whim, you're going to be out of luck. (And, along the
>way, you might find out how much work is already going into maintaining
>it -- work, like much of what goes into the ports collection, that goes
>on, unheralded, behind the scenes -- unlike all the bikeshedding like
>this that goes on in public and what people seem so impressed by,
>despite the fact that, in general, nothing actually gets accomplished).
Public discussion do0es achieve something -- maybe if there was more
discussion before any coding was done we would not have limitations
hard-wired into code in a way that limits freebsd's ability to meet future
unforeseen needs. I see this discussion as a valuable contribution by all
participants to freebsd.
>
>I simply don't have the free time to rewrite it _and_ work on all the
>other priorities to which I have currently, and in the past, put so much
>time into on this project -- ones, as far as I am concerned, will have
>a much higher impact on the usability of the system.
So maybe you could find ways of using your knowledge of the existing system to
indicate a whether partial re-engineering is possible or a clean slate
approach is required
>
>Before you get all the above done, I might even be able to _prototype_
>some kind of better search mechanism and solve the more useful part of
>the problem. To me, it would clearly take far less time to do so.
I agree - but I do not see it as more than a solution of a subsidiary problem
rather than the core problem. That does not imply that a better search
mechanism would not be valuable for the short to medium term.
>
>However, as far as I'm concerned, you've destroyed your own credibility
>with what I've quoted above,
I hope you will not let Mark's ill-chosen and unjustified accusation divert
you from contributing your constructive contributions to this debate. The
issues for the community are more important that our individual struggles.
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
Roman Neuhauser
Was the script stripped by mailman? I'd like to see it.