Re: pkgsrc freeze for 2016Q4 starting on Dec 19

[Swift Griggs <swiftgriggs%gmail.com@localhost>]

On Thu, 15 Dec 2016, Joerg Sonnenberger wrote:
> Can we sit down and start pruning some things then? E.g. we have way too 
> many LibreOffice and OpenOffice versions in the tree, I think. Given how 
> heavy those packages are, that's a lot of build time.

Please, yes! That takes forever to build and there *are* way too many 
versions. I'd be happy with a libreoffice[0-9]-bin and a regular 
'libreoffice' representing the last stable version that works on NetBSD.

I don't need/want the older versions because the whole point is to do the 
very best state-of-the-art handling of .DOCX or .XLSX files. My use case 
for LibreOffice is probably pretty similar to everyone else's. When I'm 
categorically forced to use a cursed .DOCX/.XLSX file (older .doc files 
get fed to antiword and .xls to gnumeric), then I break out LibreOffice. 
That's even more true when dealing with suit-weasels since they aren't 
aware of any other format being in existence and are hostile to the idea 
that it could be possible. Recruiter-weasels are even worse. Thus, using 
an older copy of Libreoffice is not really a good idea, since M$ will make 
sure to change the format as often as they can get away with just like 
they do with MAPI and other M$ "standards".

I'm amazed there exist C++ coders who are willing to put time/energy into 
the Libreoffice project. My hat's off to them. I wouldn't even take a well 
paying job to maintain some aging gargantuan suitsy C++ bean-counting 
package; so doing it for free shows some impressive focus and dedication, 
IMO. Libre/Star/Open office have helped me out of some nasty 
oh-god-where-will-I-find-Doze-box-running-MSOffice binds, before.

Then again, who knows, maybe there are pkgsrc users who need that stuff 
for some reason I could never imagine.

-Swift