Bug #131248 for Net-FullAuto: Split the binaries/assets to another distribution?

Thu Dec 26 01:02:49 2019 PERLANCAR [...] cpan.org - Ticket created

Subject:

Split the binaries/assets to another distribution?

Hi, The bulk size of the release lies in the installer/ (mostly Windows binaries and images), demo/ (Windows binaries), and bin/ (a Windows binary). These binaries and images don't seem to change much between releases. I recommend putting these into a separate distribution e.g. Net-FullAuto-Assets that can be updated whenever the files do change. The concern is the total size of release files of Net-FullAuto which has reached around 8GB on BackPAN, equivalent to about 11% of all BackPAN. Calculations below. Source index: http://backpan.cpantesters.org/backpan-full-index.txt.gz (~12MB as of this writing) Number of releases of Net-FullAuto on BackPAN: % zcat backpan-full-index.txt.gz | grep Net-FullAuto- | grep -v '\.$readme\|meta$ ' 1195 Total size of files on BackPAN: % zcat backpan-full-index.txt.gz | perl -lnE'/.+ \d+ (\d+)$/ or next; $size+=$1; END { printf "%.1fMB\n", $size/1024/1024 }' 73445.3MB Total size of Net-FullAuto files on BackPAN: % zcat backpan-full-index.txt.gz | grep Net-FullAuto- | perl -lnE'/.+ \d+ (\d+)$/ or next; $size+=$1; END { printf "%.1fMB\n", $size/1024/1024 }' 8084.1MB The single distribution of Net-FullAuto occupies 11.0% of BackPAN. On CPAN, currently Net-FullAuto only occupies about 0.57% of CPAN due to cleanup of old releases. Regards, perlancar

Thu Dec 26 07:34:45 2019 Brian.Kelly [...] fullautosoftware.net - Correspondence added

Hi, This is a good idea, but unfortunately a bit of a major undertaking. I will begin to do this is steps. I know the backpan policy is to keep everything, but can an exception be made in this instance? I personally don't need anything more than a couple years old, and certainly more than say fifteen years old. The stuff didn't even work until about six years ago. Could you remove everything more than six years old? That would help some of your disk space issues. Development on this code comes in bursts when I have time to devote to it. The holiday season is usually one of the few times in the year where I can really focus on getting some headway made on all sorts of issues. But mostly there are long stretches where changes are infrequent. This project is entering its 2oth year, and it represents a unique capability that is not being met easily in the market place. It's still mainly a "POC" project, but a very mature one. I run circles around people using Ansible, Chef and other automation platforms for reasons too many to go into here. If I can get some traction, which I'm working on presently, this module alone "could" help to spark a Perl revival - which I think all Perl devotees recognize is DESPERATELY needed, and more so with each passing year. I'm not promising anything of course, but there is a chance here. Young people are not learning Perl at all, and to my horror, I've actually met young people coming out of computer science programs that have not even **HEARD** of it!!!! That ought to scare the crap out of any Perl fan. So while this project is a bit of a pariah, it has a very ambitious purpose and genuine promise. It's a maintenance mess right now, but it's going down on a slowly sinking ship, so at some point, it won't matter, unless Perl itself has a renaissance. Perl is still a staple on all Unix and Linux platforms, but for how much longer? Not long if a compelling new capability doesn't emerge - and soon. Thanks, and please let me know if backpan cleanup is a possibility. Brian Kely On Thu Dec 26 01:02:49 2019, PERLANCAR wrote: Show quoted text

> Hi, > > The bulk size of the release lies in the installer/ (mostly Windows > binaries and images), demo/ (Windows binaries), and bin/ (a Windows > binary). These binaries and images don't seem to change much between > releases. I recommend putting these into a separate distribution e.g. > Net-FullAuto-Assets that can be updated whenever the files do change. > > The concern is the total size of release files of Net-FullAuto which > has reached around 8GB on BackPAN, equivalent to about 11% of all > BackPAN. Calculations below. > > Source index: > > http://backpan.cpantesters.org/backpan-full-index.txt.gz (~12MB as of > this writing) > > Number of releases of Net-FullAuto on BackPAN: > > % zcat backpan-full-index.txt.gz | grep Net-FullAuto- | grep -v > '\.$readme\|meta$ ' > 1195 > > Total size of files on BackPAN: > > % zcat backpan-full-index.txt.gz | perl -lnE'/.+ \d+ (\d+)$/ or next; > $size+=$1; END { printf "%.1fMB\n", $size/1024/1024 }' > 73445.3MB > > Total size of Net-FullAuto files on BackPAN: > > % zcat backpan-full-index.txt.gz | grep Net-FullAuto- | perl -lnE'/.+ > \d+ (\d+)$/ or next; $size+=$1; END { printf "%.1fMB\n", > $size/1024/1024 }' > 8084.1MB > > The single distribution of Net-FullAuto occupies 11.0% of BackPAN. > > On CPAN, currently Net-FullAuto only occupies about 0.57% of CPAN due > to cleanup of old releases. > > Regards, > perlancar

Thu Dec 26 07:34:45 2019 The RT System itself - Status changed from 'new' to 'open'

Thu Dec 26 07:47:12 2019 PERLANCAR [...] cpan.org - Correspondence added

Hi, Just to be clear, I am not the maintainer of BackPAN. Requesting things to be deleted from it is possible (and I believe even more so now with GDPR). Though I personally tried it once a few years back and the request didn't go through. To initiate a takedown request yourself, you might want to try the Perl NOC and Barbie. Splitting some things to a separate distribution should not be too hard; I've done it a few times before. The Net-FullAuto distribution then just needs to add a dependency to the new split distribution, so CPAN client will install it automatically when installing Net-FullAuto. BTW, there are possible duplicate files too in installer/ and demo/ (puttycfg.exe, etc). On Thu, 26 Dec 2019 12:34:45 GMT, REEDFISH wrote: Show quoted text

> Hi, > > This is a good idea, but unfortunately a bit of a major undertaking. I > will begin to do this is steps. > > I know the backpan policy is to keep everything, but can an exception > be made in this instance? I personally don't need anything more than a > couple years old, and certainly more than say fifteen years old. The > stuff didn't even work until about six years ago. Could you remove > everything more than six years old? That would help some of your disk > space issues. > > Development on this code comes in bursts when I have time to devote to > it. The holiday season is usually one of the few times in the year > where I can really focus on getting some headway made on all sorts of > issues. But mostly there are long stretches where changes are > infrequent. > > This project is entering its 2oth year, and it represents a unique > capability that is not being met easily in the market place. It's > still mainly a "POC" project, but a very mature one. I run circles > around people using Ansible, Chef and other automation platforms for > reasons too many to go into here. If I can get some traction, which > I'm working on presently, this module alone "could" help to spark a > Perl revival - which I think all Perl devotees recognize is > DESPERATELY needed, and more so with each passing year. I'm not > promising anything of course, but there is a chance here. > > Young people are not learning Perl at all, and to my horror, I've > actually met young people coming out of computer science programs that > have not even **HEARD** of it!!!! > > That ought to scare the crap out of any Perl fan. > > So while this project is a bit of a pariah, it has a very ambitious > purpose and genuine promise. It's a maintenance mess right now, but > it's going down on a slowly sinking ship, so at some point, it won't > matter, unless Perl itself has a renaissance. Perl is still a staple > on all Unix and Linux platforms, but for how much longer? > > Not long if a compelling new capability doesn't emerge - and soon. > > Thanks, and please let me know if backpan cleanup is a possibility. > > Brian Kely > > On Thu Dec 26 01:02:49 2019, PERLANCAR wrote:

> > Hi, > > > > The bulk size of the release lies in the installer/ (mostly Windows > > binaries and images), demo/ (Windows binaries), and bin/ (a Windows > > binary). These binaries and images don't seem to change much between > > releases. I recommend putting these into a separate distribution e.g. > > Net-FullAuto-Assets that can be updated whenever the files do change. > > > > The concern is the total size of release files of Net-FullAuto which > > has reached around 8GB on BackPAN, equivalent to about 11% of all > > BackPAN. Calculations below. > > > > Source index: > > > > http://backpan.cpantesters.org/backpan-full-index.txt.gz (~12MB as of > > this writing) > > > > Number of releases of Net-FullAuto on BackPAN: > > > > % zcat backpan-full-index.txt.gz | grep Net-FullAuto- | grep -v > > '\.$readme\|meta$ ' > > 1195 > > > > Total size of files on BackPAN: > > > > % zcat backpan-full-index.txt.gz | perl -lnE'/.+ \d+ (\d+)$/ or next; > > $size+=$1; END { printf "%.1fMB\n", $size/1024/1024 }' > > 73445.3MB > > > > Total size of Net-FullAuto files on BackPAN: > > > > % zcat backpan-full-index.txt.gz | grep Net-FullAuto- | perl -lnE'/.+ > > \d+ (\d+)$/ or next; $size+=$1; END { printf "%.1fMB\n", > > $size/1024/1024 }' > > 8084.1MB > > > > The single distribution of Net-FullAuto occupies 11.0% of BackPAN. > > > > On CPAN, currently Net-FullAuto only occupies about 0.57% of CPAN due > > to cleanup of old releases. > > > > Regards, > > perlancar