new package system proposal

[Polytropon]

On Mon, 06 Apr 2009 22:48:01 +0100, Chris Whitehouse <cwhiteh at onetel.com> wrote:
> Hmm Polytropon you seem to be dismissing my idea with minor examples.

Actually not, because I'm a big fan of pkg_add -r. :-)

I honestly run older machines, the oldest one is a P1 150MHz with
128 MB EDO-RAM where compiling is no fun at all, even a 5.x kernel
needs 24 hours. And with the new optimizing cc, it would surely
need much more time.

If I could install, let's say, FreeBSD 7.1 on that system, use
freebsd-update to follow the security updates, and then install
software as new as possible (via a pkg_add -r like means), this
machine would make a good server without any problems. Well, I
even used it as a serious workstation, this should still be
possible.



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

I think so, too. My favourite example, mplayer, would be one of the
few problematic points, because usually a desktop user wants all the
codes, even those that are illegal in his country.



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

Yes, and it's mostly okay to get them through a regular pkg_add -r call.
Let me give this example: When I'm about to install mplayer on an
otherwise fresh system, I don't start an mplayer build in order to
compile everything needed. I usually hit ^C as soon as I see a line
of "... depends on ... not found" and add this via pkg_add -r. If
there are dependencies for such a dependency, they will be installed
as well. So I finally end up compliling mplayer, and not Gnome or
other heavy stuff.



> Since we are talking about a fixed point ports tree
> then all the lib and dependency versions would match and - voila no problem.

Exactly. Because the sources of pkg_add -r are usually a bit older
than the port mplayer itself, there may be slightly different
version numbers. But in most cases, it doesn't matter because
we're talking about subsubminor version numbers.



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

Yes, I completely agree with that. As far as I know, the correct
internationalisation *requires* compiling. A precompiled OO in
English cannot be made a German one.



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

Well, the precompiled packages are somewhat -STABLE every time.
There is no exactly RELEASE, except you're using the RELEASE
system without updating, and then the packages from the CD.
Or the packages for RELEASE from the FTP server. In every
other case, the Latest packages are used which may bring up
problems with a system that is not up to date.


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

That's why I do "install once, use then". :-)



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

That would preserve the consistency of ports and packages. While you
can use the sup files for "make update" to specify a certain point
in time of the ports tree, I think you cannot to the samt with a
package, let's say "pkg_add -date=2009-01-01 -r xmms" to fit a
requirement of a local ports tree dated at this timestamp.



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

Again, this is a good idea which would also preserve consistency. You
could binary upgrade your whole system without getting into trouble
with a certain version changing.



> Compare
> freebsd-update which I think updates everything in your base system, not
> by you choosing which bits to update.

Yes, I think it does so. Read: I didn't find an evidence yet to assume
it does not. :-)

Especially for servers, this method is very welcome for me.



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

Yeah. :-)

Furthermore, there could be short "publications" according to the
existing /usr/ports/UPDATING, e. g. mentioning that *if* you're
upgrading your system, including X, you will need this and that
modification, or it won't work anymore.



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

The problem I fear... yes, let me call it that way... is not the
compiling itself. It's the work afterwards - the work needed to
make things work again (in regards of X: the HAL and DBUS stuff,
eventually changes of the configuration files). Because I don't
have the disk capacity to make backups of the (almost properly)
working system prior to the upgrade, I might be stuck with a non-
functioning system that makes me wish that I had better waited
for 7.2-RELEASE and reinstalled everything completely from scratch.
That's not a big deal at home.



> People who install once and don't upgrade aren't interested in either
> method.

I don't think that this is always this way. I can't speak for
others, of course, but I'd like to profit from updates, and if
it's only if I decide to install a new application, just to have
a look at it, and maybe pkg_delete it afterwards. The problem that
needed libraries aren't present make this very complicated.

To give you an example: I had a 5.x installation that worked
perfectly since July 2008. Allthoug I sometimes wanted to install
something new, this wasn't possible without reinstalling everything
else. The reason was that the system used XFree86, and from some
point in time, applications for X changed their dependencies from
XFree86 to X.org. So there was no comfortable way to install
something for X.

Today, I have this problem again. I wanted to have a look at the
program Audacious (ex Audacity), but after installing it, I only
got

	/libexec/ld-elf.so.1:
	Shared object "libgio-2.0.so.0" not found, required by "audacious"

And I didn't get Gtk 2 to compile (problem with this FAM stuff),
and I stopped trying.



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

That's completely possible. At least I would enjoy a way to binary-
upgrade all the applications in a way pkg_add -r works for single
applications.



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

That's a good point. The issues with X actually make me think that
I better leave my hands off my home PC until 7.2-RELEASE, and then
install everything from scratch and add my minor modifications to
the system (things like /etc/hosts 'n stuff, you know).



> Bottom line, I think it could work, I think if it was available people 
> would use it.

Well, I would.





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