Splitting up ports.
"...@babolo.ru
> The time has come to start working on making a hierachy from teh
> ports tree..
> there are just too many ports now!
>
> I was thinking of the following kinds of taxonomic scheme:
>
> first order... basic current scheme (though
> possibly 'national' types should be handled differntly)
>
> second order: dependent on class but for example:
> audio/midi and audio/libraries audio/players... etc
> it really depends on the major class what the subclasses would be.
>
> also, net/analysis net/benchmarks net/dns net/transfer net/security
>
> etc.
>
> it's getting a bit crouded in there!
And another end :-) of tree:
I propose to group dependant ports
in one ports directory to base port, for example:
ports/x11-wm/sapphire/sapphire
ports/x11-wm/sapphire/sapphire-themes
ports/x11-wm/sapphire/sapphire-another-themes
(no sapphire-another-themes in ports now)
See ports/38593 Three level ports: Patch and new ports
as another example with some patch.
Alternative to proposed path is to enlage list
of valid categories in such a way:
VALID_CATEGORIES+= audio/midi audio/libraries ... so on.
But a list of categories become so
flexible (x11-wm/sapphire is a category
in above) so some of ports submits
will change of VALID_CATEGORIES in Mk/bsd.port.mk.
Just remove VALID_CATEGORIES check?
Separate list of VALID_CATEGORIES to different file?
different files in main (first level) category directories?
Do not check subcategories (as PR/38593)?
Sorry for bad English
--
@BABOLO http://links.ru/
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
"...@babolo.ru
> On Sun, Jun 02, 2002 at 03:15:03AM +0400, "."@babolo.ru wrote:
> > Brian Dean writes:
> > > On Sun, Jun 02, 2002 at 01:05:22AM +0400, "."@babolo.ru wrote:
> > > > And another end :-) of tree:
> > > > I propose to group dependant ports
> > > > in one ports directory to base port, for example:
> > > > ports/x11-wm/sapphire/sapphire
> > > > ports/x11-wm/sapphire/sapphire-themes
> > > > ports/x11-wm/sapphire/sapphire-another-themes
> > > > (no sapphire-another-themes in ports now)
> > > > See ports/38593 Three level ports: Patch and new ports
> > > > as another example with some patch.
> > >
> > > directory within each category. I.e., /usr/ports/devel/p5/*, etc.
> > Good point.
> > p5-* ports are not programs but modules
> > to expand given language (mostly?).
> > So hierarchy as
> >
> > ports/lang/perl5/archivers/...
> > ...
> > ports/lang/perl5/devel/...
> > ...
>
> IMO, keeping them sorted on functionality is more important. So
> ports/net/p5/...
> ports/mail/p5/...
>
> After all, they are already sorted in the categories "net perl" and
> "mail perl" where perl is only a administrative category and net
> and mail are the functional categories.
Let's look at any p5-* port.
For example ports/databases/p5-SQL-Statement
Assume I do something with SQL.
Need I in p5-SQL-Statement? No. never.
I need (may be) it ONLY if I program
something with perl5.
It is only perl language extension.
No independent meaning - only perl language extension.
So it is not interesten to you see a lot
of p5-* ports when you are looking for,
as example, some tool to display dBase III file.
And it is nothing interesten for perl
programmers see programs while looking for
perl module. Just look at current ports tree
now - they are totally different things
and separated now by names instead directory
names because of lack of hierarchy levels.
See a difference: webcopy is perl5
script to copy web sites.
It has some perl independent sence.
Edwin Groothuis
You forget that the ports are sorted on their functionality, not
on their requirements. So to counter your example, if I'm interested
in database programming under perl, I'm not interested in the (insert
random other usage for perl modules, like networking or XML processing)
modules, but they would still be there. If you're interested in
SQL, that's database related so you can find it in ports/databases
(functionality!), there you can find in everything which is databases
related, even other databases than the one you defined.
Edwin
--
Edwin Groothuis | Personal website: http://www.MavEtJu.org
ed...@mavetju.org | Interested in MUDs? Visit Fatal Dimensions:
bash$ :(){ :|:&};: | http://www.FatalDimensions.org/
"...@babolo.ru
Functionality of all p5-* ports is: extend perl.
some (ports/audio/p5-*) in audio direction,
some (ports/databases/p5-*) in some another direction.
perl is not requirement in this ports - perl
is primary target. The audio, databases are
secondary targets after main - extend perl.
Just imagine ports/lang/CPAN ports tree :-)
--
@BABOLO http://links.ru/
Edwin Groothuis
No, functionality of all p5- ports is to let you do something while
using the perl-language. Using perl is not the aim, using perl is
a way to do it.
This kind of reasoning will lead to more extreme things like:
Textproc/libxml is a library to extend the capabilities of other
programs to access/process XML files, so it belongs in lang/ and
textproc/linux-libxml is a library for the linux-emulation to extend
the capabilities of other linux programs to access/process XML files,
so it belongs in emulators/ and textproc/p6-libxml is a module for
perl to extend the capabilities of other perl programs to access/process
XML files, so it belongs into in perl/.
You see what kind of scattering it would give if you would do this?
I can change your reasoning a little to make it view the way the
ports-structure is designed now:
databases/p5-pgsql is a direction, databases/py-pyPgSQL is a
direction, ruby-dbd_pg is a direction, accessing the database using
one of these programming languages is the goal.
> Just imagine ports/lang/CPAN ports tree :-)
No thanks. With CPAN, Their goal is to extend Perl. With the FreeBSD
ports collectio, their goal is to extend the capabilities of FreeBSD.
Edwin
--
Edwin Groothuis | Personal website: http://www.MavEtJu.org
ed...@mavetju.org | Interested in MUDs? Visit Fatal Dimensions:
bash$ :(){ :|:&};: | http://www.FatalDimensions.org/
To Unsubscribe: send mail to majo...@FreeBSD.org
parv
thusly......
> > Let's look at any p5-* port. For example
> > ports/databases/p5-SQL-Statement Assume I do something with SQL.
> > Need I in p5-SQL-Statement? No. never. I need (may be) it ONLY
> > if I program something with perl5.
>
> You forget that the ports are sorted on their functionality, not
> on their requirements. So to counter your example, if I'm
> interested in database programming under perl, I'm not interested
> you're interested in SQL, that's database related so you can find
> it in ports/databases (functionality!),
(i paraphrased "[modules ... sql]" above.)
i agree that ports should be organized on their functionality ...
but why is java a special case having its own separate physical
category but not in "lang" along w/ all other computer languages?
{ i suppose java the language is in its own _first_class_
directory because of large number of various implementations
(57[0]) which outdo ruby & python, the languages, related ports
(27 combined). but still... }
...whenever i see that, i get irked to see various perl modules, for
example, distributed as they are; they should have been in their own
first class category/directory, along w/ perl5 of course.
[0] numbers are from a 6000+ tree, not 7000+, and from java & lang
subtree. most of kde, gnome, emacs, languages other than english,
etc. related ports are omitted.
- parv
--
Maxim Sobolev
2-level structure (category/portname) is assumed (for example: pkg_install,
portupgrade, portbuild, bsd.port.mk, ports www pages etc), therefore unless
someone is willing to find and fix all those places there will be no move
forward. So far I do not see somebody willing and capable of doing that.
-Maxim
>
> Julian Elischer writes:
> > The time has come to start working on making a hierachy from teh
> > ports tree..
> > there are just too many ports now!
> >
> > I was thinking of the following kinds of taxonomic scheme:
> >
> > first order... basic current scheme (though
> > possibly 'national' types should be handled differntly)
> >
> > second order: dependent on class but for example:
> > audio/midi and audio/libraries audio/players... etc
> > it really depends on the major class what the subclasses would be.
> >
> > also, net/analysis net/benchmarks net/dns net/transfer net/security
> >
> > etc.
> >
> > it's getting a bit crouded in there!
> And another end :-) of tree:
> I propose to group dependant ports
> in one ports directory to base port, for example:
> ports/x11-wm/sapphire/sapphire
> ports/x11-wm/sapphire/sapphire-themes
> ports/x11-wm/sapphire/sapphire-another-themes
> (no sapphire-another-themes in ports now)
> See ports/38593 Three level ports: Patch and new ports
> as another example with some patch.
>
> Alternative to proposed path is to enlage list
> of valid categories in such a way:
> VALID_CATEGORIES+= audio/midi audio/libraries ... so on.
> But a list of categories become so
> flexible (x11-wm/sapphire is a category
> in above) so some of ports submits
> will change of VALID_CATEGORIES in Mk/bsd.port.mk.
>
> Just remove VALID_CATEGORIES check?
> Separate list of VALID_CATEGORIES to different file?
> different files in main (first level) category directories?
> Do not check subcategories (as PR/38593)?
>
> Sorry for bad English
>
> --
> @BABOLO http://links.ru/
>
Jens Rehsack
Edwin Groothuis wrote:
>
> On Sun, Jun 02, 2002 at 05:09:30AM +0400, "."@babolo.ru wrote:
> > Edwin Groothuis writes:
> > > On Sun, Jun 02, 2002 at 03:53:01AM +0400, "."@babolo.ru wrote:
> > > > Edwin Groothuis writes:
> > > > > On Sun, Jun 02, 2002 at 03:15:03AM +0400, "."@babolo.ru wrote:
> > > > > > Brian Dean writes:
> > > > > > > On Sun, Jun 02, 2002 at 01:05:22AM +0400, "."@babolo.ru wrote:
> > > > > > > > And another end :-) of tree:
> > > > > > > > I propose to group dependant ports
> > > > > > > > in one ports directory to base port, for example:
> > > > > > > > ports/x11-wm/sapphire/sapphire
> > > > > > > > ports/x11-wm/sapphire/sapphire-themes
> > > > > > > > ports/x11-wm/sapphire/sapphire-another-themes
> > > > > > > > (no sapphire-another-themes in ports now)
> > > > > > > > See ports/38593 Three level ports: Patch and new ports
> > > > > > > > as another example with some patch.
> > > > > > >
> > > > > > > Sounds like a good way to tuck the over 700 p5-* ports into their own
> > > > > > > directory within each category. I.e., /usr/ports/devel/p5/*, etc.
> > > > > > Good point.
> > > > > > p5-* ports are not programs but modules
> > > > > > to expand given language (mostly?).
> > > > > > So hierarchy as
> > > > > >
> > > > > > ports/lang/perl5/archivers/...
> > > > > > ...
> > > > > > ports/lang/perl5/devel/...
> > > > > > ...
> > > > >
> > > > > IMO, keeping them sorted on functionality is more important. So
> > > > > ports/net/p5/...
> > > > > ports/mail/p5/...
> > > > >
> > > > > After all, they are already sorted in the categories "net perl" and
> > > > > "mail perl" where perl is only a administrative category and net
> > > > > and mail are the functional categories.
> > > > Let's look at any p5-* port.
> > > > For example ports/databases/p5-SQL-Statement
> > > > Assume I do something with SQL.
> > > > Need I in p5-SQL-Statement? No. never.
> > > > I need (may be) it ONLY if I program
> > > > something with perl5.
> > > You forget that the ports are sorted on their functionality, not
> > > on their requirements. So to counter your example, if I'm interested
> > > in database programming under perl, I'm not interested in the (insert
> > > random other usage for perl modules, like networking or XML processing)
> > > modules, but they would still be there. If you're interested in
> > > SQL, that's database related so you can find it in ports/databases
> > > (functionality!), there you can find in everything which is databases
> > > related, even other databases than the one you defined.
> > OK
> > Functionality of all p5-* ports is: extend perl.
>
> No, functionality of all p5- ports is to let you do something while
> using the perl-language. Using perl is not the aim, using perl is
> a way to do it.
>
> This kind of reasoning will lead to more extreme things like:
> Textproc/libxml is a library to extend the capabilities of other
> programs to access/process XML files, so it belongs in lang/ and
> textproc/linux-libxml is a library for the linux-emulation to extend
> the capabilities of other linux programs to access/process XML files,
> so it belongs in emulators/ and textproc/p6-libxml is a module for
> perl to extend the capabilities of other perl programs to access/process
> XML files, so it belongs into in perl/.
>
> You see what kind of scattering it would give if you would do this?
>
> I can change your reasoning a little to make it view the way the
> ports-structure is designed now:
> databases/p5-pgsql is a direction, databases/py-pyPgSQL is a
> direction, ruby-dbd_pg is a direction, accessing the database using
> one of these programming languages is the goal.
Hm, maybe just a real new way could help. I do not have a real idea,
but I see (as discussed) that there are
a) many relying libraries
b) many (script)-languages enhancement to use those libraries
c) basic tool who use those libraries
d) frontends for the basic tools
Of course, there're combinations (f.e. gettext has libintl.so and some
utility function to create/handle message catalogues.
I think, there're also some categories, f.e. server progs, utilities,
X11, Gnome, kde, ...
We've gone a way handle such a structure in a project of our company
by using a database, where the all data is included and every dataset
got's all required attributes and joins, etc.
After all, we have a little program which creates a directory structure
from this database which creates at least the same dataset in more than
one directory...
Also another browser than a shell may be needed, but I think "make search"
is a good one :-)
Last but not least: I don't think using subcategories will really help.
I think, the current way is
a) ok
b) needing a replacement by a new way.
Jens
> > Just imagine ports/lang/CPAN ports tree :-)
>
> No thanks. With CPAN, Their goal is to extend Perl. With the FreeBSD
> ports collectio, their goal is to extend the capabilities of FreeBSD.
>
> Edwin
> --
> Edwin Groothuis | Personal website: http://www.MavEtJu.org
> ed...@mavetju.org | Interested in MUDs? Visit Fatal Dimensions:
> bash$ :(){ :|:&};: | http://www.FatalDimensions.org/
>
> To Unsubscribe: send mail to majo...@FreeBSD.org
> with "unsubscribe freebsd-ports" in the body of the message
--
L i W W W i Jens Rehsack
L W W W
L i W W W W i nnn gggg LiWing IT-Services
L i W W W W i n n g g
LLLL i W W i n n g g Friesenstraße 2
gggg 06112 Halle
g
g g
Tel.: +49 - 3 45 - 5 17 05 91 ggg e-Mail: <reh...@liwing.de>
Fax: +49 - 3 45 - 5 17 05 92 http://www.liwing.de/
Greg Shenaut
>This kind of reasoning will lead to more extreme things like:
>Textproc/libxml is a library to extend the capabilities of other
>programs to access/process XML files, so it belongs in lang/ and
>textproc/linux-libxml is a library for the linux-emulation to extend
>the capabilities of other linux programs to access/process XML files,
>so it belongs in emulators/ and textproc/p6-libxml is a module for
>perl to extend the capabilities of other perl programs to access/process
>XML files, so it belongs into in perl/.
It seems to me that the best way to organize the ports hierarchy
is solely in terms of ease of maintenance--ports that require
similar skills to maintain, such as the ability to program java,
should be together. This could make it easier for a maintainer
to deal with multiple ports.
All of the other attributes of the ports: implementation language,
national language, function, level of stability/support, and so
on, should be handled through indexing.
I've found that script-assisted greps of /usr/ports/INDEX is
orders of magnitude more useful than actually hunting through
the directories by hand.
For example, using a simple "whatport graph data" script (modeled
after "apropos") yields
|bibview-2.2 -- Graphical interface for manipulating BibTeX bibliography databases
|ddd-3.3 -- Data Display Debugger -- a common graphical front-end for GDB/DBX/XDB
|p5-GraphViz-DBI-0.01 -- GraphViz::DBI - graph database tables and relations
|py-kjbuckets-2.2 -- Graph and set datatypes for Python (C extension)
|pybliographer-1.0.8 -- GUI and command-line tools for editing and searching bibliographic databases
|qscanplot-0.3 -- A program to extract data from scanned plots, graphs and figures
|scigraphica-0.8.0 -- A scientific application for data analysis and technical graphics
|steghide-0.4.2 -- Steganography tool to hide data in binary files
|xgobi-2001.09 -- Graphical data visualisation tool
The search is based solely on /usr/ports/INDEX (which could be
improved by adding keywords other than the current subdirectory
names). Note that the hits are scattered in several places around
the /usr/ports hierachy.
I then use another search to follow up, for example using the script
"manport xgobi" yields
|xgobi-2001.09(math) xgobi-2001.09(math)
|
|NAME
| xgobi-2001.09 -- Graphical data visualisation tool
|
|DESCRIPTION
| An interactive dynamic graphics program for data visual-
|. . .
| -- Tony Maher <to...@biolateral.com.au>
|
|DIRECTORY
| /usr/ports/math/xgobi
|
| xgobi-2001.09(math)
(The script used what it found in /usr/ports/math/xgobi to produce
input to nroff -man.) If this is what I'm looking for, I would then
use another script ("activate xgobi") to install it either from a
package, if present, or via "cd /usr/ports/math/xgobi ; sudo make
install".
Note that all of this is done without the user really needing to
know where in the /usr/ports hierarchy this particular port was
located, or what its full version/name is.
Back in the good old days, the /usr/ports tree could easily be used
to browse through the ports, but I submit that there are now just
too many for such a simple approach.
Greg Shenaut
"...@babolo.ru
Aim can differ - it is subjective
> This kind of reasoning will lead to more extreme things like:
> Textproc/libxml is a library to extend the capabilities of other
> programs to access/process XML files, so it belongs in lang/ and
> textproc/linux-libxml is a library for the linux-emulation to extend
> the capabilities of other linux programs to access/process XML files,
> so it belongs in emulators/ and textproc/p6-libxml is a module for
> perl to extend the capabilities of other perl programs to access/process
> XML files, so it belongs into in perl/.
Yes, pure idea is similar to your examples.
> You see what kind of scattering it would give if you would do this?
Do not afraid of thinking
> I can change your reasoning a little to make it view the way the
> ports-structure is designed now:
> databases/p5-pgsql is a direction, databases/py-pyPgSQL is a
> direction, ruby-dbd_pg is a direction, accessing the database using
> one of these programming languages is the goal.
I understand you and how port structure goes into curent
state. Just a time to rethought.
> > Just imagine ports/lang/CPAN ports tree :-)
> No thanks. With CPAN, Their goal is to extend Perl. With the FreeBSD
> ports collectio, their goal is to extend the capabilities of FreeBSD.
Subjective point of view. The same module in CPAN and in ports
has different goal. OK. That is reason not to take goal in account.
--
@BABOLO http://links.ru/
"...@babolo.ru
> Unfortunately it isn't as easy as it sounds. There are many places where
> 2-level structure (category/portname) is assumed (for example: pkg_install,
> portupgrade, portbuild, bsd.port.mk, ports www pages etc), therefore unless
was not up to day - repaired).
Some of tools works with third levels ports as is: pkgdb, pib
I do not use portbuild, pkg_install - do not try.
> someone is willing to find and fix all those places there will be no move
> forward. So far I do not see somebody willing and capable of doing that.
>
> -Maxim
>
>
> >
> > Julian Elischer writes:
> > > The time has come to start working on making a hierachy from teh
> > > ports tree..
> > > there are just too many ports now!
> > >
> > > I was thinking of the following kinds of taxonomic scheme:
> > >
> > > first order... basic current scheme (though
> > > possibly 'national' types should be handled differntly)
> > >
> > > second order: dependent on class but for example:
> > > audio/midi and audio/libraries audio/players... etc
> > > it really depends on the major class what the subclasses would be.
> > >
> > > also, net/analysis net/benchmarks net/dns net/transfer net/security
> > >
> > > etc.
> > >
> > > it's getting a bit crouded in there!
> > And another end :-) of tree:
> > I propose to group dependant ports
> > in one ports directory to base port, for example:
> > ports/x11-wm/sapphire/sapphire
> > ports/x11-wm/sapphire/sapphire-themes
> > ports/x11-wm/sapphire/sapphire-another-themes
> > (no sapphire-another-themes in ports now)
> > See ports/38593 Three level ports: Patch and new ports
> > as another example with some patch.
> >
> > Alternative to proposed path is to enlage list
> > of valid categories in such a way:
> > VALID_CATEGORIES+= audio/midi audio/libraries ... so on.
> > But a list of categories become so
> > flexible (x11-wm/sapphire is a category
> > in above) so some of ports submits
> > will change of VALID_CATEGORIES in Mk/bsd.port.mk.
> >
> > Just remove VALID_CATEGORIES check?
> > Separate list of VALID_CATEGORIES to different file?
> > different files in main (first level) category directories?
> > Do not check subcategories (as PR/38593)?
> >
> > Sorry for bad English
> >
"...@babolo.ru
> In message <200206021...@k7.mavetju>, Edwin Groothuis cleopede:
> >Textproc/libxml is a library to extend the capabilities of other
> >programs to access/process XML files, so it belongs in lang/ and
> >textproc/linux-libxml is a library for the linux-emulation to extend
> >the capabilities of other linux programs to access/process XML files,
> >so it belongs in emulators/ and textproc/p6-libxml is a module for
> >perl to extend the capabilities of other perl programs to access/process
> >XML files, so it belongs into in perl/.
>
<reh...@liwing.de> proposition about data base.
And PostgreSQL as a tool to seek in such a ports tree.
And mantain ports on commiters side.
The only dark side is that PostgreSQL is not in base system :-(
Maxim Sobolev
>
> Maxim Sobolev writes:
> > Unfortunately it isn't as easy as it sounds. There are many places where
> Yes, I understand. But ...
> > 2-level structure (category/portname) is assumed (for example: pkg_install,
> > portupgrade, portbuild, bsd.port.mk, ports www pages etc), therefore unless
> ... bsd.port.mk is easy - see PR 38593 (oh, sorry - distfiles
> was not up to day - repaired).
The patch is incomplete, because it will generate invalid
PORTORIGIN's, thus breaking all tools that rely on in.
> Some of tools works with third levels ports as is: pkgdb, pib
> I do not use portbuild, pkg_install - do not try.
See above.
-Maxim