Subject: Re: replace-all target for bsd.pkg.mk
To: None <tech-pkg@NetBSD.org>
From: pancake <pancake@phreaker.net>
List: tech-pkg
Date: 01/19/2006 16:27:49
On Thu, 19 Jan 2006 14:59:21 +0100
joerg@britannica.bec.de wrote:

> Please fix your MUA to wrap lines at 72 characters.

Why not you? :) wrapping lines makes the mail bigger (one \n every 72 chars),
and ugly to read on <72 lines terminal (like a mobile or a PDA), and a waste
of screen on bigger screens.

> On Thu, Jan 19, 2006 at 01:54:55PM +0100, pancake wrote:
> > The "good" way is using pkg_comp and pkg_chk, but this is only available
> > for NetBSD systems. I've been maintaining some boxes (Open,Free and
> > GNU/Linux) for years with pkgsrc using the replace with no critical problems.
> 
> There's no inherent technical reason for pkg_comp being NetBSD specific.
> As I tried to explain in private mail, it is actually quite easy to add
> support for all BSDs and a bit more work for Linux (no simple
> installworld or tarball extraction).

Do you think? the mount_null stuff is very easy to modify, and requires no source
changes, just configuration changes, but pkg_comp needs a duplicated system.

pkg_comp uses the distfiles of pkgsrc. on other BSDs you can do something
similar, but not under non-BSD systems. So pkg_comp is not a viable option in
my case.

I don't like to waste disk space on my machines. In fact I have not much free
disk space. Use pkg_comp is stupid in most cases, But I understand it's an useful
tool for the people who wants to compile binary packages for a set of NetBSD
boxes. But in my case I only have 2 NetBSD boxes, one ppc and another x86, so
it remains unuseful again. And the rest are Free, Open and GNU/Linux|HURD.

So...using pkg_comp is not very useful/possible in my case.

Everybody says that disk-space is cheap nowadays...I'll never understand this.

> > So, I think that "replace-all" feature must be inserted into the pkgsrc
> > framework to allow experienced users to do this kind of things, but of
> > course showing a warning message about the problems related to this.
> 
> replace-all is inherently *much* more dangerous than replace. The effect
> of the latter is bound to a single package and can normally evaluated
> easily, the former has a global meaning and is therefore a lot more
> likely to break something. Especially with the average desktop software
> mess of 300+ packages, the likeliness of some incompatible changes in
> any of them is very high.

Ok, I understand that my patch will never be applied to the official pkgsrc tree.
So, I don't want to cause more problems to dummy users.

> Users tend to ignore such messages. Just look at some Gentoo "expert"
> suggesting to compile all software with -O3 -march=pentium3 -ffast-math,
> of which at least one option is known to break algorithms.

Gentoo is not pkgsrc.

> > Another "bug" related to the "replace" target is that replacing a package
> > depends on pkg_tarup, and this is not installed/checked by default,
> > so pkgsrc shows an error missatge saying that no pkg_tarup is installed.
> 
> pkg_tarup is incompletely and normally not needed. Why should it be
> installed by default?

I'm not saying this, I'm just saying that pkgsrc must check the existence of
pkg_tarup before using't.

> If you worry about downtime, build in a chroot. Whether pkg_comp exists
> for your platform or not, doesn't matter. You can't be serious about
> downtime and suggest replace at the same time, which can randomly kill
> your system during an update in such a way that it is found only much
> later.

I don't want to waste disk space building inside chroots. Most of my boxes are
differents OSs and ARCHs, so sharing binary packages is not very useful in my
case.

I think that this is more a personal opinion than a technical one. You think that
replace-all is dangerous and maybe buggy and cause problems and I think that
replace-all is just a nice hack that allows me to upgrade software easily and
faster.

Ok, I understand that my patch will never be applied to the pkgsrc, so I will try
to handle the discussion in another way:

Why not fix bsd.pkg.mk to make't more extensible? IMHO the "real-su-install" is
a very large function (about 200 lines) that could be stripped in different "stages".

- manpage compression stuff can be dropped out.
- pre-install stages could be done as target dependencies.
- plist generation
- file checks.

I also think that this function must be boxed between this.

=========
.if !target(real-su-install)

.endif
=========

By this way I would able to add my replace-all hack included before bsd.pkg.mk
and everybody will be happy.

-pancake