[PC-BSD Testing] Runports needs help
dejamuse at yahoo.com
Tue Jun 16 20:36:20 PDT 2009
Yes the runports thing is confusing and needs to be at least better explained, but in the context of using ports in general it's not so bad. If you understand the ports system well, then it makes sense. Trouble is, those most likely to use PCBSD can't be expected to understand the ports system and most should probably not bother to use it at all.
I wrote an opinion on all this and some links to help understand the ports system better, here.
--- On Tue, 6/16/09, Arthur Koziol <A-Koziol at neiu.edu> wrote:
From: Arthur Koziol <A-Koziol at neiu.edu>
Subject: Re: [PC-BSD Testing] Runports needs help
To: "PC-BSD Testing list" <testing at lists.pcbsd.org>
Date: Tuesday, June 16, 2009, 11:36 AM
Looking at the number of fixes you are posting to the Trac for 7.1.1, you
are working hard seven days a week. We are all anticipating the
upcoming release of 7.1.1 and its refinement of the 7.1 base.
For PCBSD 7.2 or PCBSD 8.0, which ever comes first, please consider this
comment for addition to the Wish List of improvements:
Improve the setup and implementation of the local user base issue
("runports") by having the runports preparatory work completed
and ready-to-run as part of the ports installation. The the
idea behind having ports installed in a local user base is a great one to
fulfill the purpose that the base system will not get broken by a user
However, while editing configuration files and running whatever shell
scripts need running is a trivial task, completing the very lengthy
"make" process is a barrier, consumes several hours or
overnight to compile, and might end in failure anyway. Right
now the local base-runports issue is causing confusion amongst users and
is therefore a barrier to PCBSD and potentially harmful to its reputation
as an easy to use operating system.
which lists several forum links where confusion surrounding the runports
problem has surfaced.
If a user chooses to install the optional ports tree (which is a big plus
for PCBSD users), he or she will necessarily need to use runports.
If the runports preparation was ready for use through the installation, a
user could select runports and thereafter follow the traditional method
to cd to the port's location,and install the port without further fuss or
Pros: Elimination of confusion, ease-of-use, easy adaptation of
PCBSD, protection from breaking the system base.
Cons: Kris will have to do more work compiling the parts for
I wonder what others think?
At the risk of sounding like I don't know what I'm doing / talking about,
I have one comment on this ports business. While still in the process of
reading Absolute FreeBSD by Lucas, I'm on the chapter detailing how to
futz around with make and all the ports stuff to update this, that and
the other. Now that I''m back at work and have an abuse box to use to
test out all the stuff I've learned from reading the book on PCBSD 7.1, I
wanted to see how much I could break or at least try and install KDE
4.2.4 since it's in ports now. After running portsnap fetch, I
anticipated it would have pulled down the necessary port info junk for
installing 4.2.4 and I could run a make install clean from
/usr/ports/x11/kde4 but doing so brings up the 4.2.1 installer. eugh?
Imagine my surprise. So, if that's the confusion reference above in Ian's
"Pros" statement, then yes, that could be a bit confusing,
especially for a shmuck like me who's still green and doesn't quite yet
know WTF he's doing. =)
-----Inline Attachment Follows-----
Testing mailing list
Testing at lists.pcbsd.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Testing