On 4/10/10 3:35 AM, Garrett Cooper wrote:
On Sat, Apr 10, 2010 at 1:45 AM, Julian Elischer<jul...@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.<sfour...@gmail.com>
wrote:
On Fri, Apr 9, 2010 at 10:11 PM, Adam Vande More<amvandem...@gmail.com>
wrote:
On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer<jul...@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.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
