From owner-freebsd-current@FreeBSD.ORG Sat Apr 10 17:03:33 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EC24106566C; Sat, 10 Apr 2010 17:03:33 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id A39C38FC0C; Sat, 10 Apr 2010 17:03:32 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 5so1455388qwi.7 for ; Sat, 10 Apr 2010 10:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=T2QYXm4vT/QBuzUfSr1EK+DHAHappLnjWGFREXZBzyY=; b=gN78wPE/yaTyYlcbH2bqpytlSXL3V9vHkgr5grFQeWgE7tXaEeiBmyStG2usobbcDE /GMkeD6wZw43Kn8AZNkaY6UtRQW0stNnxux+wutmYxNAFr6WpJKFZegPT9scvyJNSryj P01hJnfhEIaxjLgyFS3wLUwYBY1XSTeq5Sdv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gqmSIcLdGlCU4PcP9HwEHrJvNlPrbHHqDfbV0O2fv0HsDc6TJ9UuPT2XfUz+NTtACe hLP+DMJGNewrrrChXQQxGvVnke57dqY6CBVWFuGVOLj8XY+PFCejuxLbtmr6RZxfktq5 Pvq7YKg1DlwITG+LDQfps/j/2UmH4dgygnb0Q= Received: by 10.229.35.80 with SMTP id o16mr2375032qcd.93.1270919011473; Sat, 10 Apr 2010 10:03:31 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id w30sm3372964qce.10.2010.04.10.10.03.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Apr 2010 10:03:30 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BC0AF62.9050600@elischer.org> Date: Sat, 10 Apr 2010 10:03:30 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Garrett Cooper References: <4BBFD502.1010507@elischer.org> <4BC03ABA.6090309@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 10 Apr 2010 19:57:23 +0000 Cc: Adam Vande More , Kris Moore , John Hixson , ports@freebsd.org, "Sam Fourman Jr." , "Dave Fourman\(Gmail\)" , Matt Olander , Vanessa Kraus , FreeBSD Current Subject: Re: ports and PBIs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 17:03:33 -0000 On 4/10/10 3:35 AM, Garrett Cooper wrote: > On Sat, Apr 10, 2010 at 1:45 AM, Julian Elischer wrote: >> On 4/10/10 12:20 AM, Garrett Cooper wrote: >>> >>> On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr. >>> wrote: >>>> >>>> On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More >>>> wrote: >>>>> >>>>> On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer >>>>> wrote: >>>>> >>>>>> >>>>>> 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 the >>>>> bad >>>>> part? I do think there are problems, but there doesn't seem to be a >>>>> clear >>>>> defined set of what is wrong. IMO, there should be a defined set of >>>>> 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 nice >>>> 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 flux 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 single >> 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. ok that's your opinion n the matter. I for one think htat hte default ettin for PBIs to install all the dependencies, in this day of 1TB drives, makes sense and is a good capability for us to have, even if not everyone needs to use it. If you can do this with package code, Maybe you will supply the packages.. > >>>> 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-- 1 gcooper gcooper 6856203 Apr 10 00:05 >>> /usr/home/gcooper/Downloads/Irssi0.8.14_1-PV0.pbi >>> -rw-r--r-- 1 root wheel 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. We 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. why? As people have said before.. embedded folks usually want to compile everyrthing for themselves anyhow. > >>> 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.