Re: ports and PBIs

On Sat, Apr 10, 2010 at 10:03 AM, Julian Elischer <julian_at_elischer.org> wrote:
> On 4/10/10 3:35 AM, Garrett Cooper wrote:

[...]

>> 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.

It's more than just diskspace though. Consider the fact that now
you're going to lose a lot of the memory sharing between shared libs
and what-not, and now you'd have to be running N number of daemons .
Take PCBSD for instance -- do they really revision packages with
unshared dependencies, or are all of the dependencies updated at once?
This becomes a big issue as you can't have dissimilar applications
like dbus, gamin, openssh, etc running on the same system at one time.
How does the PBI layout plan to deal with this kind of conflict --
apart from jails, which would greatly increase the required
footprint...?

> If you can do this with package code, Maybe you will supply the packages..

Not quite sure what you meant here.

>>>>> 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.

Not necessarily. You have folks in embedded rolling their own stuff,
sure, but then you have groups like Montavista (now owned by Cavium
Networks) repackaging Linux for customers, providing a nominal fee for
the packages, support, and the tools, and there are large companies
(like Cisco) buying into this. It's not to say that people are going
to not roll their own solution, but many [intelligent] folks are going
towards an externally supported model instead of rolling their own
stuff. Thus, whatever the community decides is sane is what gets
adopted (unless the developers or management for the group are really
foolhardy / ignorant of what exists in the outside world, they're
steeped in existing methods that can't be easily transitioned to the
new model, or they have expendable resources to toss towards a custom
solution for specific needs).

If you guys think PBIs are so great... tell ya what -- make me and
other folks believers:

1. Produce a port with the magic PBI producing tool.
2. Produce directions on how to use said tool.
3. Make sure said tool and install method doesn't conflict with what
exists in base.
4. Capture statistics of how many people download this stuff and use
it (maybe use bsdstats?).
5. Come back when you have data proving how many people care for your
solution so portmgr and core can make an informed decision on whether
or not it should be a part of base.

Oh, and think about this too: whoever produces the tool, eats the
support costs. The project shouldn't eat the support costs until it's
a part of base, if that ever happens. Definitely take this point into
consideration because good support is not only `my package/port/PBI is
broken .. help me!' -- it's also having QA engineers on hand and
staffed to validate that the packages or PBIs are valid and functional
-- in the very least from a DoA / smoke test perspective. I realize
that this is lacking in packages / ports today, but it's something
that many folks volunteering in the project (cross-functional in bugs
area and also in ports) have wanted for a long time.

Thanks,
-Garrett