Date: Tue, 31 Jan 2012 01:52:19 +0100 From: Polytropon <freebsd@edvax.de> To: David Jackson <djackson452@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Unable to upgrade packages on FreeBSD Message-ID: <20120131015219.7f3e9e75.freebsd@edvax.de> In-Reply-To: <CAGy-%2Bi-bwgvf9UbMq0zUqPSzqPGcf%2B=Dv1pncbsL2AW6=80niA@mail.gmail.com> References: <CAGy-%2Bi-6GLfoUuhUExjnVEKhM00TuUimhKuhboLkjBeXNk9hFg@mail.gmail.com> <20120130215826.140fa9df@mpw> <CAGy-%2Bi9pYgB3VjG8KQg98Bfr5Ax2BOLOnuqrzOe_P5juDe%2BVjw@mail.gmail.com> <20120130234946.e2747081.freebsd@edvax.de> <CAGy-%2Bi-bwgvf9UbMq0zUqPSzqPGcf%2B=Dv1pncbsL2AW6=80niA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 30 Jan 2012 18:40:50 -0500, David Jackson wrote: > On Mon, Jan 30, 2012 at 5:49 PM, Polytropon <freebsd@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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120131015219.7f3e9e75.freebsd>