PBI Systems

Well tis time to plan for war or for peace. I can only see two roads before me.
In a funky branch of science where psychology and history meet at a decision
point that breaks into two possible futures. At first I didn't know which to to
choose but then it just popp'd in there. A man has great capacity for both good
or evil, it's this choice that splits that destiny apart.

While one could harbor malice towards some thing is normal for a human, I have
none to use. I've long rejected such ideas in favor of ones that work. So, I
see that I must take the option that poses the least threat.

On one road, I see the changes to the PBI system to be used (read abused).
Using both volume and redundant checks of quality control push the PBI system
for all it's worth till it ether busts or grows strong.

To the other, adopt to it and fight for its growth. Well ether way I'm going to
raise all kinds of bloody screaming if quality control standards are not
maintained. If Pkg_add becomes the John Doe of the PBI word proper auditing and
quality management is required. The number of times pkg_add PBI have leaked
through testing even when it was strictly a case for "pkg_add -f pkg.tbz" ==
You will be skinned alive being the accepted Community/Developer standard. Even
PC-BSD Developers would occasionally bend this rule and bypass auditing (or
worse...). SO what the heck, why not go with it.

This is a change I hoped to see come with a much stronger infrastructure and a
larger user base. Hopefully one done after proper documentation was ever
created. To be honest PBI documentation is kinda, uhhh scratched out? Yet how
does this change come to us ? By a loss of principals - it wasn't after people
complained. It wasn't after user after user put up requests on the wish list
only to be mostly ignored. It wasn't after people yelled for a more traditional
approach, it wasn't after die hard FreeBSD people turned there noses at the
idea. It wasn't that a flaw was found in an imperfect system and a fix was
needed. It wasn't that as it is the PBI system couldn't work. It's simply that
they would rather have it done NOW then later. Why work to make some thing work
the way it was supposed to? When you can just change the rules to match your
hand of cards ? I'm sorry but thats the way I feel - I don't mean to accuse any
one and don't.

We can now use pkg_add in PBI creation at a very small level because it's the
easy solution. When a problem of commercial importance chopped up. Well excuse
me and my big fat Johnny Reb ass but I'm starting to agree with a few FreeBSD
sys-admins. A clean, functional, elegant design should be the end result. Not
some thing hacked together with chewing gum and cloths pins. Even after public
debate about the similar issues they didn't care - they get a problem getting a
commercial app to abide by it and they change the rules. When I had "offically"
left working on any PBI I did so seeing a system showing signs of reform, one I
knew would stand. Now I see it caving in on it self.

Ok so we have to live with pkg_add app PBI full of libs not added ok now we need to think here. The pkg_add can only be the main app well if we draw that line very easy at cd /usr/ports/cat/app && make package && cd /usr/local/Projects/PBI && mkdir app && cp /usr/ports/Packages/All/app.tbz ./

Then we need to check this package to make sure it only contains libs unique to
the project or else fool around /w it and the +* files to make a new package to
force or risk breaking some thing. Ok thats good enough but what if we have
some problems loading a Lib out of /Programs/$1/libs at run time ? OK well
since the PC-BSD Devs say it's ok to do a pkg_add of the main app. Why don't we
just move that into it's own PBI and pkg_add that after making the user install
it :-P Heck The lead Developer included a handful of Linux RPMs to make one of
his PBI work since it was a Linux program any way (which was not pkg_add'd IIRC)

Now we have a simple case here - We need to test if the pkg is all ready
installed abort it with an error to the user. When removing it it would be nice
if we could do a fast check to see if any thing depends on the package, such as
user installed ports !!!!!!!!!!!!!!!!!!!!!!!!!! und abort the uninstall
accordingly. I.e. Make sure for totally clean install/removal of pkg's not just
force them in/out with a sledge hammer like a dumb fuku! Trust me I've seen it
a lot of times. It would also be nice if the user updated a PBI using ports if
we could just *remove* things from the PBI Uninstall menu.

Ok so that sorts that now. What about docs on PBI creation ? We got a few how
to make XYZ FAQs on the FAQ. Other wise it's horse dung. For example one of the
best tutorials says to tarball stuff inside the PBI which is basically a
compressed archive all ready. Kris Moore tells me not to do that - any one see
that in documentation ? HELL NOOOO!!! So we see a few PBI using it that
followed that tutorial. I'm oh most afraid to go to the SVN if you see my
train of thought here.

I see a possible return to PBI Development if I'm made to live in this words
new concept of PBI. There was only a few reasons I never jumped off the boat
and swam for FreeBSD shore after learning I could live without PC-BSD. I saw
PC-BSD as the brightest hope for the future, not only for Unix on a Desktop but
as a real operating system, world class. That was one of the reasons I didn't
just drop off the scene. So here I am for better or worse it seems.

I think I may start compiling a list of ports to prepare PBI's for in this "new
order" try to get a mass production thing going once I have time to get every
thing ready op. Then let operation Justice-Rainbow commence, details classified
with only beneficial results for PC-BSD included. I'm not sure yet for this.

Do I really want PC-BSD to succeed in every way possible? Yes but can I support
a project I feel has issues with ethical, moral, and principal concerns I'm not
sure. Well ether way I hope www.pbidir.com will see so many PBI coming in they
won't know what to do with, I only hope they are the right kind. The good kind
made with love and craftsmanship - not shoddy pieces of crap that brings a
Graphical RPM Installer into this new world. Some people know what my feelings
are about RPMs..


Sigh, even though I know I must follow the light course I think they would
deserve it if I took the darker path. I just can't willingly do that....
(censored). I've got a lot on my plate right now. I've got studies in 6
languages + html/css, I want to install lighttpd/mysql/php on my FreeBSD box so
I can study PHP. I still have not set up my printer. I've got to redo a history
test that the USPS lost, least it wasn't my final (upper 90s pass). I gotta do
a Biology course *joy*. I'd love to just set to work on what I want to do. I'd
love to just dive in to things and create the program I know I can do given the
right time... A strong language reference and documentation database and
inhaling a few dozen manuals, learning ether QT or GTK based GUI development.
PBI it and vola oh how I wish I had the time... With a week off if I didn't
have School I could put a nice dent into a few things that really need them
done. C and Ruby are my friends, it's time I get to know them better and have
a go with QT me thinks.