Re: Making it easier to get and use pkgsrc

[Aleksej Saushev <asau%inbox.ru@localhost>]

David Brownlee <abs%netbsd.org@localhost> writes:

> On 11 December 2010 21:03, Aleksej Saushev <asau%inbox.ru@localhost> wrote:
>>
>> David Brownlee <abs%netbsd.org@localhost> writes:
>>
>>> 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.

Do you know that joke about the horse designed by committee?

If you're going to ask about defaults, you assume that user should read
the list of defaults, the legend for said list, and he should think how
those defaults apply. How is that easier than reading README?
If you're going to simplify things, you should rather: ask no questions,
generate log, and provide recovery tool.

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

bootstrap/bootstrap has sane defaults already, and it provides easy way
to override them. How is your proposal makes life easier?

If user doesn't have enough space, he works under constraints that require
him to think. We may expect that he has agreed to read documentation.
Note also, that if you can't extract pkgsrc tree, you'll run into space
problems most likely anyway; 1G doesn't make the weather.

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

Sorry, I don't buy it. I suggest that we recall this argument when most
platforms have said wget or ftp. Besides this plays bad in isolated network.

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

This is exactly the most annoying part in self-downloading packages,
first they promise that everything is fine, thus distracting you from
possible issues, then you discover that you're blocked by no-network
issue, while you could spend 15 minutes to read instructions and...
Go all the road which isn't that long!

> 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

I think that when optimising one should think more than just automatising.
What are you trying to optimise away?

Compare this:

"Download this script, run it. It will do all the bootstrap for you.
If anything fails, see README."

"Download archive, script, and README. Put them into the same directory.
Run the script. If anything fails, see README."

Note that above you've "optimised" away 2 mouse or keyboard clicks,
and introduced at least one more point of failure.
All in the name of two or three words on web page.

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

It is controversial, if we should default to unprivileged if run unprivileged.

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

If we're going to insist on creating binary packages, someone(tm) should
thing about tools to roll installation back to some point. Otherwise
having binary packages on file system only wastes space. And it is more
than 1G after some time.

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

This needs more thinking, and it plays bad with make(1).

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

I find that using mk.conf for system builds after build.sh is mostly useless.
If build.sh is considered the main tool, then the default should be reversed:
build.sh should set MAKECONF=/dev/null unless told otherwise.

The alternative is to revive direct builds and support more options
that justify use of make(1) not only by developers and hardcore hackers.


-- 
HE CE3OH...