Re: Making it easier to get and use pkgsrc

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

On 11 December 2010 21:03, Aleksej Saushev <asau%inbox.ru@localhost> wrote:
>
> David Brownlee <abs%netbsd.org@localhost> writes:
>
>> One of the 'non NetBSD specific' suggestions was to make the initial
>> pkgsrc tarball available via a shorter convenience URL such as
>> ftp://ftp.pkgsrc.org/pkgsrc.tar.gz (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.

Agreed - I'm sure there are already well defined names for the various
versions, it may just involve providing shorter paths, plus sane
defaults, eg pkgsrc.tgz links to the latest pkgsrc-nnnnQn.tgz

>> 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 ftp://ftp.pkgsrc.org/pkgsrc.tar.gz
>>
>> - 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.

I would suggest at least one question - "are you happy with the
defaults [y]", so users can just hit return and have it do "something
sane". Or possibly just a couple of lines explaining what its going to
do, and to run it with '-h' for help.

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

Maybe the user does not have enough space on /usr to extract into
/usr/pkgsrc, but otherwise the script is good for them. The defaults
should be sane, but there should be an easy way to override them. I'm
happy to make the overrides all command line options if that is the
general consensus.

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

Most platforms will have a wget or ftp which supports downloading a
URL. Otherwise it can exit and say "provide a working wget or download
http://.../pkgsrc.tgz into the current directory"

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

Using pkgsrc on an non network connected system is very much an edge
case - as you will not have any automatic way to get distfiles either!
In this case I would assume you would use one of:
a) Script exits with error and including URL to download to current
directory to continue
b) You follow the "getting pkgsrc" README, (which we still need to
provide) and run the download, extract, and config steps by hand.

The script is only automating a few steps, and will display the
commands before it runs them
- download appropriate pkgsrc tarfile
- extract tarfile into specified location
- potentially create a mk.conf/pkgsrc.conf with some config
- build bootstrap if required
- point the user at the README in the extracted pkgsrc

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

I would definitely want the script to be able to extract an existing
pkgsrc tarfile. Also one option would definitely need to be configure
a bootstrap for user specific rather than root install.

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

Agreed its controversial - (thats why its under "potential" :) I think
pkgrsc should be creating binary packages by default when building,
but I'm not going to push against the world to make it so. Though If
not the default I *do* think any setup script should have an option
(only if the user goes looking) to "make it so".

Actually that may be better handled by a pkgsrc-config script which
inexperienced users could run, though I'm always wary of automated
clever scripts which rewrite config files. We need something to make
it easier for a non-expert user who wants to tweak config to get
things setup. There are just too many things they can set right now
and no easy way to surface the things they are likely to need. Anyway
- very happy to come back to this at a later date.

>> - Move PKG_DBDIR under PREFIX
>
> I agree with this.

Its trivial to switch the default. Its migration thats the issue. I
assume the ideal way is to make the default be to build pkg_install
binaries which look in both the new and old locations and refuse to
run with a warning if they find both, and to use the new if they find
neither...

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

The reason I want to switch it out from mk.conf is that on NetBSD
mk.conf is used by all the system build. I think pkgsrc should have
its own file, not mixed in with anything that happens to be used by
bmake in general. I'd be happy enough with it looking in a pkgsrc
instance specific location, though I think it should be in PKGSRCDIR
not PREFIX.