Date: Sun, 02 Jun 2002 12:26:48 +0200 From: Jens Rehsack <rehsack@liwing.de> To: Edwin Groothuis <edwin@mavetju.org> Cc: .@babolo.ru, ports@freebsd.org Subject: Re: Splitting up ports. Message-ID: <3CF9F2E8.A8E7611F@liwing.de> References: <20020602100945.B553@k7.mavetju> <200206020109.FAA03318@aaz.links.ru> <20020602114341.C553@k7.mavetju>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > edwin@mavetju.org | Interested in MUDs? Visit Fatal Dimensions: > bash$ :(){ :|:&};: | http://www.FatalDimensions.org/ > > To Unsubscribe: send mail to majordomo@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: <rehsack@liwing.de> Fax: +49 - 3 45 - 5 17 05 92 http://www.liwing.de/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CF9F2E8.A8E7611F>