new package system proposal

[Polytropon]

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.

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.

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.

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.

(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.



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.



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



> 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. :-)



> - 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 think this could work because I think the default config options are 
> probably suitable for most desktop users so it wouldn't be necessary to 
> create loads of different binaries for the same port, [...]

I may disagree and bring (only) one example: mplayer. Reason:
codecs. Most users I know who dislike compiling always take
the time to get the maximum out of mplayer, and this cannot
be achieved using pkg_add.


> [...] and security 
> considerations are not so important as for server admins.

Don't say that. An incorrectly administrated desktop can develop
into a massive threat to others on the Internet. Do you know that
most spam, data espionage, malware, viruses etc. are distributed
by home PCs (even if they are placed in a company's network)?



> It might be possible to distribute the actual compiling to users with 
> spare cpu cycles, a bit like the SETI at home projects etc.

I'll reserve some spare cycles for you with my for(;;); program. :-)

	



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