tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Making it easier to get and use pkgsrc


David Brownlee <> writes:

> It has been suggested that we should make it easier for users to
> download and start using pkgsrc.
> One area of disagreement is whether we should be providing an easy
> command on NetBSD to download the main pkgsrc tarball, such as
> DragonFly's make targets in /usr, or if we should always keep the
> interface cross platform, so users on NetBSD download the pkgsrc
> tarball the same way as any other OS.
> One of the 'non NetBSD specific' suggestions was to make the initial
> pkgsrc tarball available via a shorter convenience URL such as
> (which I think is a great idea).

It would be useful to have pkgsrc-current.tar.gz link too.

Also counterparts with another compression methods: .tar.bz2 and
.tar.xz (if/when we use it).

I'm not sure yet, but perhaps providing access under conventional names
like pkgsrc-2010Q4.tar.gz would be nice too.

> I'd like to suggest we try to make the cross platform experience as
> easy as possible, for something NetBSD specific sysinst could
> bootstrap the local pkgsrc using that method.
> So, some possible areas.
> - Make the initial pkgsrc tarball available via a shorter convenience
> URL such as
> - Provide a 'setup-pkgsrc' shell script which prompts for a couple of
> parameters (eg: pkgrsc location, current vs release), *with sane
> defaults*.

I strongly disagree with the first half of this proposal.
Script, if any, shouldn't ask anything.
If you're going to simplify it, make it really simple.

The second half partly contradicts the first one.
If you request to provide sane defaults, then why ask questions?
That should be covered by defaults.

> This would download and extract pkgsrc, runs bootstrap if
> required, and direct the user to read the README in the extracted
> pkgsrc when done. It could display the commands before they would be
> executed, helping new users who want to understand *how* more than
> just *what* is going on. NetBSD distributions could potentially
> include this script.

Is it possible to automatise downloading cross-platform?
I seriously doubt it.

Self-downloading scripts only sometimes make your life easier, in many
cases they are plain annoying. Consider what happens when I want to
quickly deploy pkgsrc on a system in isolated network. Or on system
that has restricted access to network. Do you mean that I'm to jump
through the hoops to open network access and close it again?
How is it supposed to make installation easier?

If you do want to simplify the life, this script should unpack already
existing pkgsrc.tar.gz and bootstrap within current directory,
producing $(pwd)/pkg, $(pwd)/var, and perhaps setting DISTDIR=$(pwd)/distfiles
and PACKAGES=$(pwd)/packages.

> - Provide PKG_PATH settings so users can pickup binary packages for
> their system (setup-pkgsrc could be the route for this, defaulted on,
> but able to switch)
> - More binary packages (and more kudos for those already working on
> providing the existing binary packages), including bootstrap setup for
> !NetBSD
> Some other random *potential* cleanup
> - Default to DEPENDS_TARGET=package-install and UPDATE_TARGET=package-install

This is controversial. Some people won't like it.
We need "package-clean" target rather.

Perhaps, a target to call pkgtarup would be useful.

> - Move PKG_DBDIR under PREFIX

I agree with this.

> - Switch from mk.conf to pkgsrc.conf

...And disagree with this. This is useless cosmetic change that breaks
previous patterns. bmake looks for mk.conf at a precise location already,
if you have two different pkgsrc installations on your system, you'll
see that two bmake instances don't overlap unless specifically forced.


Home | Main Index | Thread Index | Old Index