[nycbug-talk] a clarification about the csup/CVS announcement

[George Rosamond]

On 01/13/13 13:46, Brett Wynkoop wrote:
> On Sat, 12 Jan 2013 20:35:43 -0800
> Pete Wright <pete at nomadlogic.org> wrote:
>
>> On 1/11/13 11:02 PM, Glen Barber wrote:
>>> On Sat, Jan 12, 2013 at 01:48:26AM -0500, Brett Wynkoop wrote:
>>>> FreeBSD-10 ARM == no-packages
>>>>
>>> Package building on !x86 platforms is a touchy topic.
>>>
>>> FWIW, it is something I have heavy interest in solving, but right
>>> now, lack of access to !x86 architectures for me is the showstopper
>>> at the moment.
>>
>> ok let's make this happen :)
>>
>> https://www.edis.at/en/server/colocation/austria/raspberrypi/
>>
>> only sort of kidding...i'd chick in some money to help if there is
>> interest....
>
> Pete-
>
> When USB is working on the BeagleBone I intend to hang enough disk on
> one of my boards,  I have 2 at the moment and plan on getting a third,
> to be able to build common packages and have them for people to grab if
> desired.
>
> For my own part I am not a fan of packages.  I have been building most
> things I use from source for 30 years.  I only grab a package when I
> can not get the source to build for some reason.
>
> I prefer building and installing from ports because then I get to build
> with the options I want.  Many programs have build time options.  I
> also know that the resulting binaries are linked against the versions
> of libraries I have on my system.  This seems to be more important in
> the elf world than in the a.out world.  Can anyone explain to me why an
> elf binary that was compiled on a system using libfoo.so.1 refuse to
> run if you have libfoo.so.2 instead?  In the days of a.out binaries the
> program would try to run in the case of libfoo.so --> libfoo.so.2
> instead of libfoo.so.1.  If it ran it would issue a warning saying it
> had a library mismatch.  I have wondered why the difference for years.
> Maybe someone on the list can explain it to me.
>
> Of course you can work around the elf issue by installing the old
> library, or symlinking to the old name, but it does make using packages
> a pain if you have updated anything on your system beyond when the base
> release was made.


That's all very legitimate, and I generally stick to source (from ports) 
as the preferred method.

However, there's a few things to keep in mind with an embedded system 
like FreeBSD ARM on a BeagleBone:

1.  There's usually (or should be) a narrow purpose to the system, and 
the number of applications installed is minimal.

2.  Prebuilt and custom packages will be simple enough (as in pkg_create 
now)

3.  Pkgng will make a lot of the difficult issues in the past 
irrelevant, as in the port and package versions will be kept 
synchronized, not as the current state where a port is updated and 
patched, while a package is a bit behind and may have a vulnerability 
that's even noted by portaudit.

4.  Not sure if freebsd-update is there, but it will be *my* tool for 
updating the base system, since all your talk of building worlds and 
galaxies is scary on a credit card-sized board with 256M of RAM.

I think Eitan mentioned (or I imagined) that packages will become the 
preferred method of application install instead of ports, which was 
always the case with OpenBSD.  It means not having to maintain local 
ports trees on embedded platforms, via NFS, USB or whatever.  Solve the 
storage issue and you still have a relatively slow processor.

Since I maintain a bunch of FreeBSD-based Soekris and Alix boards, I 
always prebuilt packages based on already installed ports with whatever 
options I need.  On occasion I had issues, but these are not multi-user 
systems, and are again, narrow in their function, and don't have a 
boatload of dependencies.  Of course, bootstrapping packages off of i386 
for i386 platforms is simple enough...

I know there is discussion of easing cross-platform building of 
packages, which would be another wonderful change.  So use that old i386 
box to build your custom ARM packages and be happy, at least some day.

g