Hmm Polytropon you seem to be dismissing my idea with minor examples.
I am convinced it could work, and that people would appreciate it. I've
tried to answer your points, apologies if I have misunderstood any of them.
Compiling applications in general will lead you into one
main problem: Many ports have different options that need
to be set at compile time. For a set of n options, 2^n
packages would be created, if I consider the WITH_SOMETHING
It's true but many ports would not be included in this desktop package
set. I suspect still that plenty of people would be happy with defaults
for many of the desktop apps.
One example is mplayer. Its various options select which
codecs to include or if / if not to build with mencoder.
In regards of different national law, it may even be
prohibited to include a several codec, so it needs to
be installed afterwards manually.
i think Matthew deals with this one in his later post. But ok maybe
there are one or
two ports for which you provide a binary with default config but many
people recompile it anyway. They would still have all the dependencies
already installed. Since we are talking about a fixed point ports tree
then all the lib and dependency versions would match and - voila no problem.
Another example is (you mentioned it) OpenOffice. In the
past, I was happy to do
# pkg_add -r de-openoffice
or something similar. Today, I'm happy that someone put
a precompiled package of OpenOffice online and announced
it on the de- mailing list.
So you would be keen to have OO available. So would a few other people
judging by the openoffice topic going at the moment.
The topic internationalization comes into mind here. I'm
not sure how OpenOffice decides which language to use,
maybe this is to be set at compile time, too.
Yes this occurred to me after I made my inital post but I think Matthew
deals with this one as well.
(Side note: I prefer good english language in my programs
instead of poor german translation which is quite bad.
OpenOffice, and in the past StarOffice, is the only
exception for me.)
As you see, I am a big fan of pkg_add, but it doesn't work
in every case.
No because the packages are built on a rolling ports tree. The crucial
difference is that the whole thing is a type of ports-snapshot so
On Sat, 04 Apr 2009 15:13:22 +0100, Chris Whitehouse <cwhi...@onetel.com> wrote:
Ports is rightly a flagship element of FreeBSD. The benefit is
configureability and consistency. The obvious downside is it takes so
long to update a desktop machine with a normal set of ports installed,
particularly lower spec hardware or laptops.
pkg_add somewhat addresses this but it doesn't work quite as well as
ports because of possible version mismatches.
It's always good to use an "integrated tool" such as portupgrade or
portmaster to get rid of such problems (like pkgdb -aF). It allows
automating the updating process, but as you know, something can
happen and the update stops during the night.
yes this is a downside of upgrading by compiling from ports, regardless
of whether you use portmanager portupgrade or portmaster. I'm trying to
avoid the necessity of the update happening through the night at all.
Modify pkg_add so that it can be told to use this 'snapshot' including
downloading the fixed ports tree that was used.
You can tell pkg_add to get packages from a completely differnent
place, this doesn't need a modification of this system's program
itself. But a kind of "wrapper" would help here.
The modification is that pkg_add with --ports-snapshot option (or a
completely new utility) would hook into this "ports-snapshot" which
consists of a ports tree and a set of packages which are built from
'this' ports tree. Maybe the only change is that pkg_add gets the ports
tree snapshot from which the ports were built.
I think it is also implicit that if you download a new snapshot you get
the ports tree plus all the packages installed on your computer that
have been upgraded since your
last snapshot. You would not use it by downloading the ports tree
snapshot and choosing only to upgrade certain ports. Compare
freebsd-update which I think updates everything in your base system, not
by you choosing which bits to update.
Some benefits to this system are
- don't need to mess with portupgrade etc.
I always felt that tools like portupgrade make things easier, not
messier, but I'm oldfashioned, so don't give anything on my very
individual opinion. :-)
Yes the ports-mgmt utilities are useful. Still quite a lot of list time
is spent on problems around upgrading ports, regardless of the utility
used to do the upgrading. A centrally managed set of packages would have
access to a group of experts who would be able to fix problems quickly
(using the time they didn't have to spend on answering questions on list
(I have always had a lot of success with portmanager, would you be
willing to try it? I would be
- it generally increases the useability of FreeBSD as a desktop system.
Well, when we're talking about desktop systems, there are the
both two big philosophies:
(a) install it once, use it then
(b) always upgrade
There are (reasonable) needs for both concepts, and they may
even mix. Thinking about the problems / difficulties that came
up with the recent X.org update, my X is still in (a) state. :-)
interested to know the result)
People who install once and don't upgrade aren't interested in either
method. Some people will always want to roll their own with the ports
system. But I reckon there are plenty who would appreciate a package
system that worked _as well_ as the ports system, not "nearly as well".
Which to me justifies my proposal :-)
Actually your example of the problems with X is a good point. How much
better would it be if you could pkg_add --ports-snapshot and you get
everything upgraded with no hassle, including the new version of X.
Sometimes there would be longer between updates because of major issues
like the X one.
Bottom line, I think it could work, I think if it was available people
would use it.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"