On Mon, Dec 13, 2021 at 08:00:02PM +0000, Stuart Henderson wrote: > On 2021/12/13 11:18, Chris Bennett wrote: > > cpan: > > p5-CPAN-DistnameInfo > > p5-Crypt-URandom > > p5-Data-Binary > > cpan is not a valid category, it is just where portgen puts things that it > has just built, they need moving to whichever real category is most > appropriate. >
I know, I just really wanted to point out on the list with this thread that there are a lot of ports involved with this. I ran this just to put up a sorta right list so that others could see that I'm not whining about having to do just a couple of ports. > > p5-DateTime-Format-Duration-ISO8601, > > p5-Email-Stuffer > > p5-Feature-Compat-Try > > p5-File-PathList > > p5-Locale-CLDR > > p5-Locale-CLDR-Locales-Ar, > > p5-Locale-CLDR-Locales-Bg > > p5-Locale-CLDR-Locales-Ca > > I explained what to do with the CLDR-Locales ports and subdirectories before > I haven't forgotten that. I lost access to -current before I could get to them. I have re-read those older emails recently. > btw, from your mail from October > > : So, I found bringing in Core::Thingy a problem I didn't see a reasonable > way to > : accomplish. > : Who wants to review 12 new ports a once just to bring in p5-Core-Thingy? > : Submitting such a ridiculous email chain was preposterous! > : > : I never did get any advice on this aspect of the problem. Depressing. > > That is unfair, this is one of the things I explained about in my > mail from 2019, "So for the smaller perl ports I'd try to group them > with a chunk of say 3-5 closely related ports (one port plus required > dep's, or a couple of similar ports" > What I didn't see was to work outwards to inwards. It just didn't occur to me. There were some difficult problems to work out with postgresql database interactions with the p5-PGOject* ports that required a lot of work on my part and with some help. I really don't understand at all how the postgresql-mod.mk works. I know what it accomplishes, but I would love to actually "get it". Most of what I do besides porting uses postgresql. I am also working on a project for myself that I intend to release that works with neomutt and postgresql to pull out configuration files on the fly from the database. I'm using it right now to run my neomutt with different email addresses within a perl wrapper. Still very WIP. Life hands us whatever it hands us. Fair/unfair/earned/unearned/deserve/don't deserve in my opinion is all BS. Working hard or hardly working doesn't really have any effect in life. Both can produce success or failure. I think that luck runs on some kind of Bell curve. Nobody would be called lucky unless there was somebody unlucky. >From my point of view, submitting ports and watching many others getting new ports and updating existing ports committed is....... I will look in the ports archives to see if any of the ports I'm working on already had work by someone else. That's a very good idea. I do listen, maybe I'm just not as bright as I used to be. }-) > Date: Mon, 4 Nov 2019 11:50:23 +0000 > From: Stuart Henderson <s...@spacehopper.org> > To: Chris Bennett <cpb_po...@bennettconstruction.us> > Subject: Re: I'm starting to port LedgerSMB and it's dependencies > > On 2019/11/03 16:18, Chris Bennett wrote: > > Hi, > > LedgerSMB is accounting software. I started porting the dependencies in > > a good while back, got most in and developed about 2-ish others on the > > side which let me provide an installation guide and the software extras > > on an informal basis to get up a working system. I never managed to get > > it all in the ports tree. Life moved on and LedgerSMB has developed > > extensively since then. https://github.com/ledgersmb/LedgerSMB and > > https://ledgersmb.org/ > > > > It works on PostgreSQL and multiple web servers. I would like to include > > a guide on using base httpd, but I don't think I would be a good source > > for coming up with that help. > > Don't get hung up on making it work with httpd. The normal LedgerSMB > installation runs it from Starman with a reverse proxy in front of it > handling HTTPS etc - nginx/apache can do this easily, httpd cannot act > as a reverse proxy at all, it might be possible to get it working with > relayd but it's often a complete pain to work with! Better to get it > committed first, it's easy to add further notes in a pkg-readme later. > > > Any help bringing in the new ports would be welcome, but since everyone > > is so busy, I'll happily settle for good criticism! > > There's a ports hackathon starting *tomorrow* so if you can get some > things sent out fairly quickly there's a good chance of getting a decent > chunk of this committed quite soon. > > Information-dense mail follows, if you can follow it, it will greatly > improve chances of getting things in :) > > Looking at https://github.com/ledgersmb/LedgerSMB/blob/master/cpanfile > and the ports tree, we have many of the dependencies and in the right > versions already. Some new ones are needed; > > core - > HTML::Escape > PGObject > PGObject::Simple > PGObject::Simple::Role > PGObject::Type::BigFloat > PGObject::Type::DateTime > PGObject::Type::ByteString > PGObject::Util::DBMethod > PGObject::Util::DBAdmin > Plack::Builder::Conditionals > Plack::Request::WithEncoding > Version::Compare > > X12 EDI Support - > X12::Parser > > PDF and PostScript output - > Template::Latex > Template::Plugin::Latex > TeX::Encode > > OpenOffice - > OpenOffice::OODoc > OpenOffice::OODoc::Styles > > Excel - > Excel::Writer::XLSX > > (I have ignored "develop" for now). > > Don't try to do everything in one go, concentrate on 'core' first. > > Search ports@ archives for past attempts, review feedback if any. > > Create fresh ports with "portgen p5 $modulename", this will usually > get you 80% of the way (you'll need to replace the default "cpan" > category and adjust paths to use a proper category and review > COMMENT and DESCR as the generated ones are usually a bit poor). > If there was a previous attempt, compare that with the new portgen'd > one and decide which is better to go with. > > For mailing out proposed ports, you want to give porters a chunk that's > enough to work on without too much back-and-forth (especially as you're in > a different timezone to most active ports devs) but without flooding > them. > > Avoid having separate active email threads because nobody will remember > which have been reviewed/committed and which need more work - usual result > of this is that people will tend to ignore the whole lot. > > So for the smaller perl ports I'd try to group them with a chunk of say > 3-5 closely related ports (one port plus required dep's, or a couple > of similar ports - using an example from here with PGObject you'd want > to start with the core + required deps, then once they're reviewed and > committed send out some of the other PGObject::foo ports). Send them > in a single tar so a reviewer doesn't have to mess about to get them > unpacked and into the correct dir's. > > If a port is more complex then a single port per mail usually makes more > sense, but make sure everything needed to review that port is either > already committed, included in the same mail, or has a direct link to > the full URL for any tarballs/diffs needed (don't make people search > list archives to try and find some other submission which may or > may not be the right version etc!) > > I have just sent out HTML::Escape + deps to ports@ which can act as > an example of how to do this. (I forgot to do so, but better to mention > *why* you want them e.g. that they're a dependency of LedgerSMB which > you're working on). > > When you get feedback try to react quickly while there is still momentum. > > > I do have a general question that never even occurred to me. I used > > Godaddy briefly and then have run baremetal servers since then. > > The site talks about possibly setting up a Perl copy in a home directory > > and/or using local::lib to use what's needed for LedgerSMB when unable > > to get the needed packages installed. > > > > It made me realize that there have to be quite a few people with that > > problem. What are your thoughts and experiences with that? It was a real > > OOH! for me remembering that others run into this. > > That's really for locally installed things, if you're intending to put > something into ports then the dependencies need to be in ports too. > -- Chris Bennett
