Date: Mon, 06 Apr 2009 22:48:01 +0100 From: Chris Whitehouse <cwhiteh@onetel.com> To: Polytropon <freebsd@edvax.de> Cc: User Questions <freebsd-questions@freebsd.org> Subject: Re: new package system proposal Message-ID: <49DA7891.6090708@onetel.com> In-Reply-To: <20090404170401.c0f0bce0.freebsd@edvax.de> References: <49D76B02.4060201@onetel.com> <20090404170401.c0f0bce0.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Polytropon wrote: > 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 > options only. 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 everything matches. > > > > On Sat, 04 Apr 2009 15:13:22 +0100, Chris Whitehouse <cwhiteh@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 :) ) > > > >> - 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. :-) (I have always had a lot of success with portmanager, would you be willing to try it? I would be 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. Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49DA7891.6090708>