Re: ports and PBIs

On 4/10/10 3:35 AM, Garrett Cooper wrote:
> On Sat, Apr 10, 2010 at 1:45 AM, Julian Elischer<julian_at_elischer.org>  wrote:
>> On 4/10/10 12:20 AM, Garrett Cooper wrote:
>>>
>>> On Fri, Apr 9, 2010 at 11:28 PM, Sam Fourman Jr.<sfourman_at_gmail.com>
>>>   wrote:
>>>>
>>>> On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More<amvandemore_at_gmail.com>
>>>>   wrote:
>>>>>
>>>>> On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer<julian_at_elischer.org>
>>>>>   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.