more ports more deps harder index

[Peter Vereshagin]

Wake me up when September ends, freebsd-perl!

I maintain some module on CPAN and its p5- port as well.
Module has a feature and impose some more dependencies to satisfy system administrators, e. g. the most of FreeBSD users. ;-)
The feature in question is programmer-interfaced because of agile Perl nature. But wanted for admins, too.
Recently I noticed the feature was taken as the only reason to put someone else's module on a CPAN.
The code of the module itself, besides its *.t tests is no more than 10 lines of code but due to the Perl nature it's not a reason to decline it. Anyway, it's nice for my module to extend it and make it easier cause the feature in question will be implemented by another CPAN author in this case ( and probably more properly, too ).
The drawback for this case will be the ongoing Ports index overhead. Imagine there will be 1 more port, more index length, longer portupgrades and so on. Only because of that 10 lines of code to work in conjunction. The more such a cases, the harder regular system maintanence becomes. How good is all that about to be still this way?
Since it is a good practice to put more CPAN modules on a Ports, yes, I had put my module to a Ports some time ago. But there are several features  in, so I thought twice before. Now I'm about to make development more distributed wioth CPAN, right. But in terms of ports collection this can make it closer to monster-style bloatware, isn't it? That's a question.
Yes, I can simply incorporate those ~10 lines of code into my CPAN module but that is not why the social stuff like CPAN,github,sourceforge, etc. exist in terms of best coding and porting practices, right?  Secondly, the module itself is the primary thing in relation to its' port, right? So I'm about to guide in my development by the code quality interests' considerations, not the porting ones.
Technically, the difficulties appear on difference of CPAN and ports use. With CPAN, there is no need on special packages index, the dependencies are checked by mean of regular module including by far, With FreeBSD Ports/Packages, there are /var/db/pkg directory search and pkgdb/portsdb reindexing after every module install, and this make system portupgrade process significantly longer and less predictable on every port addition to the index.
I know that agile Perl people do never rely on system packages cause those use to be outdated for them, for example for FreeBSD the one should file a PR even for every small but sometimes so-sad-it-is-not-yet-in change on a module. There is no such a need to update a CPAN module. No, PRing is not that bad or hard work, it is not that significant but wanted stuff, e. g. if some FreeBSD user is satisfied with module he/she will use it with no problem at all and no his/her attention is needed for such a problem to be a problem of someone other's system, not his/her, so this shouldn't be an announce.
I differentiate such a Perl modules ports questions cause such kind of software is rare to be used as a development preview before to be packaged as a system package. It's hard to make an unusable but forthcoming code in ~10 lines of code. But this can consume ~30+ lines of code for OS packagers to write up, is it a good practice?
Partially, such kind of problem should be solved by mean of tools like Slackware's cpan2tgz or Red Hat's cpan2rpm, but this should be more dependency-walky and system-integrated solution, since for my module's target audience, the system administrators, the dependencies are the matter of OS.
Yes, this could be a much wider question, like same can go her for php's PEAR, tex's CTAN and so on. But the most care in terms of ports quantity and my person is, yes, Perl p5-* ports. Potentially we can make 16K p5-* modules, is it any good for FreeBSD to have that amount volume of packages more that can make it almost twice bigger?
So, what I can see from out there is: the unified interface for such kind of modules, standing in a cloud as an automated porting system spreading on peer-to-peer base with no care about the module porters who admin these ports for their own. And, sharing them. If such a share should be with the Ports collection system, ok. If via the something different (web or p2p resource like that easy to use openbittorrent), this should be ok, too. But the FreeBSD regents, in my opinion at least have to take care on conflicts resolving in such a cases the users can have these days when FreeBSD Perl users do install modules via the CPAN.pm despite them exist in a ports. This is another reason of Ports out-of-sync-ing, right?
Besides the reason of my own to think about it mentioned before, another one is: the perl6 is stabilizing at recent years and the p6-* ports seem to be their way.

73! Peter
-- 
http://vereshagin.org