Date: Wed, 05 Nov 2014 18:49:07 -0800 From: Jeffrey Bouquet <jeffreybouquet@yahoo.com> To: freebsd-ports@freebsd.org Cc: ports@freebsd.org Subject: Re: Reducing the size of the ports tree (brainstorm v2) Message-ID: <545AE1A3.9070309@yahoo.com> In-Reply-To: <1415234542.3472540.187608725.1C104533@webmail.messagingengine.com> References: <mailman.1.1415188800.63945.freebsd-ports@freebsd.org> <20141105162003.EFA3A6F0@hub.freebsd.org> <1415223045.3436045.187536433.49F9A27E@webmail.messagingengine.com> <545ABA5A.2040105@yahoo.com> <1415234542.3472540.187608725.1C104533@webmail.messagingengine.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/05/14 16:42, Mark Felder wrote: > > On Wed, Nov 5, 2014, at 18:01, Jeffrey Bouquet wrote: >> On 11/05/14 13:30, Mark Felder wrote: >>> - duplicate packages registered in pkg_info >> I could simply /bin/rm -rf the duplicate subdirectory. >> > Your're treating the symptom not the problem. This solves nothing and > leaves potentially vulnerable, untracked libraries and binaries on your > system and you can't be sure which one future port builds are linking > against. Explain please how the problem of one erroneous directory among thousands means they are all removed and hidden behind an SQL I know nothing about and which may segfault. (Just wishing pkg recodes a switch to put them back maybe as an optional readout after each install, if that does not in and of itself segfault...) We are trading one unreliability for another maybe? >>> - leftover files *everywhere*. find /usr/local -type f -print0 | xargs >>> -0 -n50 pkg_which | grep "not found" >> A small price to pay for stability. And what if pkg which (sqlite) is >> more prone to >> breakage, obsolete libraries, wrong compiler >> libmap... vs pkg_which >> which >> could be resurrected as a backup... I hope continually >> > I don't understand which faults you're trying to point out here. > Breakage and obsolete libraries? pkg-static.... What if pkg-static does not work? I deinstalled seven ports to save space, and "pkg-static install -f port" wanted to reinstall them right back. csound for a non-audio non-multimedia port for example... With the old system I could debug it with pipes. I've no SQL experience, so that v9 is stagnant for now, with a local.sqlite too large to email anywhere... > >>> - broken binaries discovered via pkg_libchk >> One can easily have that now, pkg upgrading to ruby20 default when >> ruby19 is still >> installed or something... or my limited experience is not the norm >> > No you can't. pkgng doesn't install packages without their dependencies. > This would all be fixed by the next package set. No temporary interim breakage? > >>> This is disgusting. You might as well just be extracting tarballs and >>> not using a package manager because the only benefit you're gaining from >>> the old ports tree is the automation of *building* and *installing*. >> Portmaster handily handled the switches -d -B -P -i -g (ports unless >> packages upstream) >> Why disparage that? Pure packages is not for everyone, and that in >> itself AFAIK is a >> feature not a bug of FreeBSD... >> > Portmaster is not part of FreeBSD, and why are we relying on a third > party tool to fix bad design? > Explain bad design? Portmaster, which worked well, hours on end at the end of a pipe with xargs? Or the ports tree again? >>> Here's the lifecycle of a typical pre-pkgng server: >>> >>> 1) Install FreeBSD >>> 2) Install your ports/packages >>> 3) Server is in production >>> 4) Attempt to update ports/packages >>> 5) Disaster is now waiting to happen >> 3a... Production? update on a second machine, roll out to the main one. >> No disaster. > But how do you get the updated ports/packages onto the production server > without building them? I surely hope you're not building and installing > them on another server and manually copying the files/libraries over. If > you used a package server (tinderbox) that same concept is what we're > recommending. Manually copying the files over, or better "mount -o union" and portmaster on the next machine found them already fetched. Tinderbox beyond my expertise and more expensive than a simple thumbdrive > >>> Every time you need to update you might as well rm -rf /usr/local and >>> start over. >> I upgraded 5 > 5 > 5 > 6 > 7 > 8 > 9 and instances within each one, >> losing mutiple >> hard drives, but files in /usr/local still exist from 2004... > This is terrifying for reasons previously explained. This is not a server. No worries. >>> Some ports even barfed all over the base system, so >>> reinstalling wouldn't be a bad idea either. >> I read reinstalling not a bad idea, but only in the problematic case. >> > Untracked libraries and executables all over your OS is a problematic > case. I've pipes to take care of them. >>> The goal is to make pkg the norm and ports the very rare exception. >> Why 'very rare? ' I always thought that they were to work in tandem. >> Isn't tweaking of >> ports on one's machine consistent with knowing the ins and outs of all >> the ports as well >> as package workings? Make targets? etc. >> > Mixing packages and ports is *not* supported and never has been. This is > another cause of unnecessary bug reports. Elaborate? If it can happen, does happen, works, is advantageous, and does not mean bug reports... I do not ever recall seeing a specific warning that it is not supported, just that it may be better to not mix them. Not supported would seem to indicate many users should go to other operating systems... > The only "tweaking" you should be doing is changing port build options, > and they'll be available via (sub)packages according to the current > roadmap. Only in rare circumstances should you need to manually build > ports. My apologies. I was not aware of this roadmap... I still suspect that the robustness of the port build system should take precedence over that of the package management system. >> not having any poudriere >> experience > This is very simple to solve, and I think you'll love it. You get all > the power of ports and confidence in your system. This is only a desktop with backups. Sorry... no time. >> , not >> knowing how many low-powered routers pkg may not work on, > pkgng is faster than pkg_ in many ways. I don't see a concern here. Takes more memory with a large number of installed ports? Pkg is young in the timeframe of FreeBSD >> having disks >> that may >> not upgrade well with pkg2ng if ever... > You're basically asking pkgng to be able to import data from an > unsanitized, schema-less database with no constraints and have it work > perfectly. Not even divine intervention could make this work reliably. Explain unsanitized? I installed a port, its registry (the subdir) appeared with almost always accurate information. Explain schema-less? One file to describe, one to list dependencies, one to list ports which depend on it... Explain my asking pkgng? I joined the lists early on to ask that it be optional, and a few of my concerns have transpired to be not unfounded. I still believe reliability could be coded back in... say installing a port OR a package ran the pkg registration AND the /var/db/pkg registration, and pkg-compare-legacy did a cross-check to discrepancies... I see the best of both worlds there. Then, one could maybe set one as "master" method the other as "slave" method for whichever suits ones install better, if one (some better shell or .c coder than I for instance...) took the time and trouble to code it up... test... > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?545AE1A3.9070309>