Re: Making it easier to get and use pkgsrc

[David Brownlee <abs%netbsd.org@localhost>]

On 11 December 2010 23:59, David Holland 
<dholland-pkgtech%netbsd.org@localhost> wrote:
> On Sat, Dec 11, 2010 at 08:14:26PM +0000, David Brownlee wrote:
> Â> It has been suggested that we should make it easier for users to
> Â> download and start using pkgsrc.
> Â> [snip]
>
> All this discussion seems futile and rather silly, because it seems
> fairly obvious that the correct approach is to have sysinst offer to
> download and unpack /usr/pkgsrc, either stable or HEAD as desired.
>
> This should be straightforward, really.

For non NetBSD pkgsrc users there should be a simple easy way to
get setup on pkgsrc. I think sysinst should just call this same method.

> Â> - Default to DEPENDS_TARGET=package-install and
> Â> UPDATE_TARGET=package-install
>
> as pointed out already, this is wrong. (and we can't switch to
> USE_DESTDIR by default, btw, until someone fixes undo-replace. See PR
> 43689.)

Thanks for the PR ref.

> Â> - Move PKG_DBDIR under PREFIX
>
> This is a bad idea. As I've said before, PKG_DBDIR contains exactly
> the sort of data that is supposed to live in /var: mutable indexes and
> databases that reflect the state of the system.
>
> Surely you don't also think it would be a good idea to move the
> comparable base-system data from /var to /usr? (e.g., the locate
> database, services.db, /var/db/obsolete, and so forth.)

I think thats not a good analogy. The pkg db files are more akin to
/etc/mtree than var/db/services.db.
They only change when packages are added or removed, not during normal
use of the system.

> Â> - Switch from mk.conf to pkgsrc.conf
>
> I'm not sure this is a good idea. On the one hand, it avoids needing
> the magic knowledge that pkgsrc is make-based; on the other hand, you
> have to know that to do anything with pkgsrc. I think if we're going
> to move to something that advertises itself specifically as pkgsrc
> configuration that it should be restricted to configuration statements
> that make sense for pkgsrc and not necessarily be an arbitrary make
> fragment... but that would cause regressions if we aren't careful.
>
> However, I do tend to think that things should be self-contained and
> that the *base system*'s build should use $(TOP)/mk.conf (or maybe
> $(TOP)/config.mk, but within the tree) rather than a file in /etc.

A file under PKGSRCDIR would make me happy - I'm less concerned about the name