Date: Sat, 10 Apr 2010 03:35:04 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: Julian Elischer <julian@elischer.org> Cc: Adam Vande More <amvandemore@gmail.com>, Kris Moore <kris@pcbsd.com>, John Hixson <jhixson@gmail.com>, ports@freebsd.org, "Sam Fourman Jr." <sfourman@gmail.com>, "Dave Fourman\(Gmail\)" <dfourman@gmail.com>, Matt Olander <matt@ixsystems.com>, Vanessa Kraus <vmkraus@gmail.com>, FreeBSD Current <current@freebsd.org> Subject: Re: ports and PBIs Message-ID: <q2q7d6fde3d1004100335ucf424ae0gbfcdba950fd68767@mail.gmail.com> In-Reply-To: <4BC03ABA.6090309@elischer.org> References: <4BBFD502.1010507@elischer.org> <r2w6201873e1004092011y829fe434w724ccde9cbf78e2c@mail.gmail.com> <o2z11167f521004092328z50ed9c9zde0294a344439709@mail.gmail.com> <x2i7d6fde3d1004100020oc8be3c51ree5f1e4b07b99f45@mail.gmail.com> <4BC03ABA.6090309@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Apr 10, 2010 at 1:45 AM, Julian Elischer <julian@elischer.org> wrot= e: > On 4/10/10 12:20 AM, Garrett Cooper wrote: >> >> On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr.<sfourman@gmail.com> >> =A0wrote: >>> >>> On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More<amvandemore@gmail.com> >>> =A0wrote: >>>> >>>> On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer<julian@elischer.org> >>>> =A0wrote: >>>> >>>>> >>>>> Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some >>>>> others and I, felt that these ideas seemed to make some sense >>>>> and so I put them here for comment. >>>>> >>>>> >>>> FWIW, when I see these discussions I'm always left wondering what's th= e >>>> bad >>>> part? =A0I do think there are problems, but there doesn't seem to be a >>>> clear >>>> defined set of what is wrong. =A0 IMO, there should be a defined set o= f >>>> goals >>>> to judge possible implementations against. >>> >>> >>> Let me start by saying FreeBSD ports is by far the best system I have >>> used to date. >>> but as good as it is, there is room for improvement. >>> >>> Being a FreeBSD user now for many years, one thing I think would be nic= e >>> is: >>> being able to have easier access to development ports( Masked ports >>> kinda like Gentoo). >> >> Masking ports and packages in general introduces all sorts of fun new >> complexity for end users as well as maintainers. The last time I used >> Gentoo (which was only a matter of months ago), a lot portage packages >> were still masked even though they've been stable for months, years, >> etc. This is very annoying for me as an end-user because bug blah >> could be fixed in a later release but in order to unmask the pieces >> for version blah, I had to unmask 10~15 other `unstable packages', >> which greatly increased the chance of instability on my system (this >> was particularly the case back several years ago, but Gentoo has >> become more conservative over the years, and appears to be approaching >> some level of equilibrium with Fedora, Ubuntu, etc in terms of >> releases and package versioning). >> >>> right now is a GREAT example, currently there are new Gnome ,KDE and >>> Xorg. >>> these are all MAJOR ports,dependencies run deeper and deeper with every >>> release. >>> there can never be enough testing...but they all exist in random >>> subversion servers around the web... >> >> ports isn't going to solve this. Post the Xorg modularization (which >> needed to occur anyhow because Xorg and Xfree86 before that was were >> monolithic beasts), I personally don't see that change in the amount >> of =A0flux on a quarterly cycle, and the number of packages I install >> today isn't that much greater than back 6 years ago when I started >> using FreeBSD. So, while there might be some claim here to note, I >> think it's mostly exaggerated. >> >>> I would very much like to help test these Major ports, but installing >>> them is a pain. >>> there should be some sort of overlay system in place, so I can just >>> build the development ports >>> after agreeing to a few well placed warnings of course. and Well if I >>> hose my system all to hell.. >>> well then I could just click on a bunch of PBI's and I am back in >>> business... >> >> Ok, apart from the interface (click a PBI, and magically you have >> packages installed)... how is this really different from binary >> packages? Have you tried installing binary packages lately via >> pkg_add? If not, I'd give it a shot instead of installing from ports. > > > yes but there are still dependency problems if you want to install a sing= le > package and you installed all the previous ones a year ago. > With PBIs each package is self standing, so you can install one > and not worry if it requires a different version of some library > to what you installed last year. If I'm understanding you correctly you're saying it's an issue when I do: pkg_add A B C # 1 year passes pkg_add D # D depends on A, B, C, of different revisions. pkg_add barfs because it can't find the applications, etc. This is something that's been hashed over a number of times (a few of which I've participated in in #bsdports). There needs to be a simple update command which will handle the action of upgrading packages, because there isn't a proper command that will do so today. Unless PBIs are self-contained entities which have their own sets of dependent utilities and libraries, etc (which you weren't suggesting in the sentence above), or install into a common location with versioned directories (which is a pain in the ass and involves a lot of hardcoded pains dealing with libtool files, libraries, etc -- been there, done that with Gentoo Linux -- there are hack scripts written to work around several possible hardcoded version issue, and there are a handful), AFAIK there's nothing positive and new that PBIs can bring to the table in this regard that can't be implemented in pkg_install as-is, other than the point-click-install user-friendly interface. >>> better still, make the development ports a PBI, I am just thinking out >>> loud here,but that may work, toughts? >>> >>> one could say I could use merge scripts like marcusmerge for example, >>> or use Virtualbox... >>> but for large ports like Xorg and gnome or KDE, virtualbox doesn't cut = it >>> yet... >>> thinks like Nvidia Video cards, multiple monitors, USB devices, and >>> whatnot do not work on virtual box.. >>> PBI's for development ports, with all the dependencies, wrapped in one >>> package. >> >> Ok, well here's the thing. Instead of having N shared dependencies and >> libraries in /usr/local/lib, you'd have N**2 shared dependencies and >> libraries in each and every package. Now, let's look at > > > >> $ ls -l irssi-0.8.14_1.tbz ~/Downloads/Irssi0.8.14_1-PV0.pbi >> -rw-r--r-- =A01 gcooper =A0gcooper =A06856203 Apr 10 00:05 >> /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi >> -rw-r--r-- =A01 root =A0 =A0 wheel =A0 =A0 517442 Apr 10 00:07 irssi-0.8= .14_1.tbz >> >> The .tbz file is a file created with pkg_create -b, and the other file >> is the PBI I pulled off of http://www.pbidir.com/bt/download/210/2079 >> . Big difference in size (13.25 fold difference). > > Yes but that is a worst case thing. =A0We are talking about making > a system where the PBIs contain all the libraries needed but that > only some of them are installed, when there is not already the > same one (i.e. identical) installed by a previous PBI. > so if you installed, say, 20 PBI from the same 'set' you woudl only > be installing one copy of the libraries that See above comment. >> PBIs only comprise a small set of packages in FreeBSD; if my >> understanding is correct based on a mirror referenced in pbidir.com, >> the number is currently under 500~750 PBIs -- this is drastically >> smaller than the number of binary packages produced by ports on a >> regular basis for FreeBSD. >> >>> solution? well let all the developers develop working ports in >>> progress in one place, give users like me a way to track these changes >>> and install and test them... I think FreeBSD becomes a better place for >>> it. >> >> Packages are more of the answer IMO, not PBIs. PBIs are merely a >> different set of contents and different means of delivering those >> contents, and while I like the idea of point - click - install, I'm >> not ready to create unnecessary complexity by having libraries rev'ed >> according to what the maintainer A believes are correct, even though >> maintainer B set it differently, and I'm not interested in sacrificing >> disk space for this reason. If I wanted to use a packaging scheme like >> this, I should be using Mac OSX as my primary operating system. > > well no-one is going to make you use PBIs Yes, but if I now have to waste more bandwidth and disk space installing packages, why shouldn't I go to another operating system? Switching over to PBIs will reel in more desktop and entry-level sysadmins, etc, but I fear that it will isolate folks in the embedded market as well as several more seasoned users because of the implications involved with the extra bandwidth requirement and footprint. >> Thanks, >> -Garrett >> >> PS Don't let this discourage you though in considering the entry-level >> user case. I'm just apparently more insane than some folks (not as >> insane as some others though), and I just don't believe in this >> ideology because things are fine for me as-is.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?q2q7d6fde3d1004100335ucf424ae0gbfcdba950fd68767>