Unable to upgrade packages on FreeBSD

Tue Jan 31 00:52:22 UTC 2012

On Mon, 30 Jan 2012 18:40:50 -0500, David Jackson wrote:
> On Mon, Jan 30, 2012 at 5:49 PM, Polytropon <freebsd at edvax.de> wrote:
> 
> > On Mon, 30 Jan 2012 17:04:56 -0500, David Jackson wrote:
> > > I wish to use binary packages and I specifically do not want to compile
> > > anything, it tends to take far too long to compile programs and would
> > > rather install some packages and have it all work right away.
> >
> > That's often true, especially when you're low on resources
> > (CPU speed, disk, RAM).
> >
> >
> >
> > > Binary
> > > packages are a big time saver and are more efficient.
> >
> > More efficient? Depends. In regards of installation, they're
> > often faster. In regards of spped during operation... well,
> > depends. :-)
> >
> > The binary packages are compiled from the ports sources with
> > the maintainer's default options. Those options might not
> > perform optimal on _every_ imaginable system. That's why
> > compiling from source can make programs run faster when
> > certain optimizations (e. g. specific CFLAGS, selection
> > of CPU at compile time) are applied. Also functionality
> > may increase as the default options may leave something
> > out.
> >
> > A common example is mplayer: When compiled, it can have
> > much more functionality and can even work wonders on old
> > systems. The binary package doesn't give you that.
> >
> That is true. Well, unless is a problem with cross CPU compatability, all
> available options should be compiled in by default. Mplayer (or it was some
> video players) has a huge number of display targets for instance, they can
> be runtime selected so support for all of them can be compiled in  my
> default and the user can then select which one to use at runtime. I have
> used video player where you can choose between OpenGL, plain X11, Xvideo,
> and many other display options and I actually liked having these kinds of
> runtime choices.

It's not just the output drivers, it's also the codecs.
There's a sheer plethora of them, and there are basically
three kinds of users:

a) I only install the codecs where I have the corresponding
   files to play; I don't want any other codecs.

b) I want all the codecs, so no matter what file I get, I can
   play it without further installation.

c) I'm frightened because I live in a country where playing
   MP3 is forbidden by law, so I better not install anything
   that could make my elected government suspicious and send
   me a federal trojan. :-)

Okay, two kinds of users.

In addition to the codecs, there's another thing that mplayer
can be selected upon compile time: if to include mencoder.
Further stuff includes gmplayer and gmencoder and the skins
for those programs.

Regarding CPU feature use, it seems that WITHOUT_RUNTIME_CPUDETECTION
(or what the option was called like) in combination with
over-optimized CFLAGS and CPUTYPE create a faster binary,
especially on older systems.

> A package for these programs can be provided and if a user needs a compile
> time option they can then spot compile them as needed.

The default options (which the maintainer chooses) do not
meet any of the two kinds of users mentioned above. In
fact, I would call the default mplayer "partially optimal"
because it's not the "full thing" and also not the "minimal
thing".

> > Other things to keep in mind are language settings. One
> > example is OpenOffice which needs to have the language
> > setting at compile time, especially if you're not using
> > the english language.
> >
> >
> You could compile a version of that for each language and I think thats
> what Ubuntu does, or, just compile maybe top 1 or 2 most commonly used
> language version and then other versions could be user compiled.

There are, I think... at least 10 languages available, and
combine this with Gnome, KDE and CUPS support OFF or ON,
and you have 10*2*2*2 = 80 packages, and still no scheme
to name them. :-)

> > Finally, there may be licensing restrictions that forbid
> > the distribution in binary form, or even the distribution
> > through the FreeBSD system. Traditional Java may be seen
> > as an example.
> >
> >
> This is rare, but it happens. Most programs dont have this problem. a few
> programs must be compiled like this, it is a lot easier to compile that
> handful of programs for me than it is to compile the entire system.

I fully agree. If I remember correctly, mpg123 has been such
a program, but compiling that is nothing compared to KDE. And
with the shrinking importance of Java... :-)

> > > It should be easy for
> > > FreeBSD to make it easy to install the most recent versions of all binary
> > > packages, its beyond belief they cannot pull off such a simple ans
> > straight
> > > forward, and basic part of any OS.
> >
> > Again, it depends. The options maintainers define as the
> > default are typically okay for the build clusters that
> > process them - they create the binary packages from the
> > ports tree. At some occassions, options and dependencies
> > can take into account things that are already installed,
> > e. g. "foo" uses "bar" if "bar" is installed, but if it's
> > not installed, it fetches and installs "baz" instead.
> >
> > Just imagine how many packages you would need to map all
> > possible combinations of dependencies present, options set
> > and languages available, and _then_ come up with a naming
> > scheme for the packages. :-)
> >
> >
> Just compile package for the package download site with all optionals and
> functionality available. If it has optional dependancies, just install all
> of the dependancies when the package that needs them is installed. Then
> user can has all features avialable at runtime.

Sadly, many programs have been developed to contain "hard-
coded" dependencies, so they do not react dynamically on
what's currently installed.

For example, Gimp tries to query CUPS via lpstat commands.
What if no CUPS is installed because it's not needed?
(I had that observation in the past, but could simply
ignore it as the system's default printing facility could
still be used.)

Of course it would be better to break up programs into
modules that can be installed per ports or packages
independently, and maybe three metaports as Robert
suggested: one for a working bare minimum, one for a
typical installation, and one that has everything.
This makes three packages.

To make use of such a concept, many programs would have to
be re-engineered and freed of bloat, and maybe different
bload needs to be added then. :-)

> If its an one or the other type option, compile with the most commonly used
> setting.

How to determine that?

> In many cases they use run time options in programs so this is not as much
> of an issue in those cases.

Oh, if they all did in reality... :-)

> if people want to make their own compile time options then they can resort
> to compiling the package themselves.

That's a typical situation because those who use FreeBSD
on a daily basis seem to have a certain amount of control,
which is exercised via source code, therefore ports.

> Probably throw in all options at compile time for packages, such as HAL,
> and then it will be available if people need to use it. If people dont want
> a component, then they compile on their own. 

You see, that's exactly what I had to do. Not because I like
it, but because I have no other choice. When certain components
just make a system NOT work, getting rid of them is to use the
source. So I could say: Using ports isn't only about including
stuff, it's also about excluding stuff. I don't know how those
two opinions are balanced.

> As far as dependancies, the
> program can be compiled to rely on them and they would be installed
> automatically when  the depending application  is installed.

Hmmm... the problem when they are _not_ installed would raise
much more questions if those dependencies are required to get
the program running. A port defines BDEPS and RDEPS, those
needed for building (irrelevant when using packages) and those
required for running. It would be a bit complicated to divide
the RDEPS up into RDEPS_ESSENTIAL and RDEPS_OPTIONAL, but the
approach is interesting.

> Im not sure what HAL does but Ive installed it for X Window System, if it
> makes it work better, I have no problem with installing HAL.

In my case, it makes X stop working, so I had to get rid of it.
I simply have no use for it.

Currently - just to give you an example - I'm forced to use CUPS.
I have no need for it, and it doesn't even fully work. But the
Opera web browser seems to have lost the ability to print PS to
the system's default printing facility, because it desperately
wants CUPS. So I installed and configured it, works for most
programs, but not for normal text: As soon as a non-US_ASCII
character is encountered (e. g. a german Umlaut or Eszett),
the output stops.

I found that in case of trouble you better know WHAT you have
installed and WHY. I don't like to install stuff just to have
it installed. The problem is not disk space occupied. The
problem is many latent variables that come unhandy when
diagnosing problems, because you NEVER know.

> > > The reason that FreeBSD has a smaller user base is because it has a
> > > dysfunctional package system and it is hard to upgrade package to the
> > most
> > > recent version, making FreeBSD more difficult to use/
> >
> > I do not agree with this statement. The user base of FreeBSD
> > consists of a major amount of people who do not use the
> > binary packages, as it seems, because ports work well for
> > them.
> >
> >
> Perhaps that is because the people who want to use packages have given up
> on FreeBSD.

I'm not sure about that. I've been using packages without many
trouble, but I don't try binary updates on them. WHERE I use
them, the policy is: install ONCE, then keep using, and DO NOT
touch it. :-)

-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...