new package system proposal

[Chris Whitehouse]

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 at 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