Re: Making it easier to get and use pkgsrc

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

On 11 December 2010 21:56, Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost> 
wrote:
> On 11.12.2010 21:14, David Brownlee wrote:
>
> IMHO, the issue is not really pkgsrc related, but rather NetBSD.
> Currently, pkgsrc does its job pretty well. However, it's original (and
> main development) platform being NetBSD, it should be made available
> easily, without requiring prior knowledge of NetBSD's ftp hierarchy, and
> extensive man page reading.
>
> Other OS provide package management systems that are quickly available
> after installation, without needing ftp browsing, untaring, and
> searching through yet_another_hierarchy on how to make and install third
> party apps.
>
> The duplicity between source and binary packages does not really help
> either. You always have two alternatives, go the binary package route
> and use pkg_add with PKG_PATH, or use pkgsrc and make install. I think a
> choice has to be made here, ultimately, regarding which solution should
> be proposed in the default case (no, this does mean that the alternative
> has to be thrown away).
>

I would suggest we should focus on binary packages for the 'one click
install' group. That is potentially including changes to the
pkg_install tools to facilitate that. If I just want to easily install
packages without building from src then I should not need to download
and keep pkgsrc updated.


>> 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).
>>
>> 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
>
> I agree. Although I would prefer to have a "pkgsrc-stable.tar.gz" (or
> "pkgsrc-release.tar.gz" file (latest quarterly release), to avoid
> confusion with pkgsrc-current.tar.gz (which should be accessible in the
> same directory, IMHO)

That works for me.

>> - Provide a 'setup-pkgsrc' shell script which prompts for a couple of
>> parameters (eg: pkgrsc location, current vs release), *with sane
>> 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.
>
> It's the idea, although I believe that having a default safe URL to
> download pkgsrc stable and current tar.gz is already a very good thing
> (especially if you point people to pkgsrc.se for quick package lookups).

I definitely see the options as non exclusive - any helpful startup
script should not be at the expense of making it
harder for someone who knows what they want to do to just download and
start using pkgsrc by hand.

>
>> - Default to DEPENDS_TARGET=package-install and
> UPDATE_TARGET=package-install
>
> I already hear someone complaining in the background :o

I think this is the item with the strongest opposing views - probably
best to shelve it
 and come back to it later, rather than tying up the rest of the thread :)

>> - Switch from mk.conf to pkgsrc.conf
>
> At first sight, I would say "yes", but I guess a .include "/etc/mk.conf"
> directive would have to be added to pkgsrc.conf. mk.conf is shared by
> NetBSD and pkgsrc bmake, so I am not quite sure that this will make
> everyone happy.

See comment in other email :)

>
> I would also add to the cleanup:
>
> - suppress warning when pkg_add'ing packages where build and target
> system have different minor revisions (e.g. NetBSD-5.0.2 vs
> NetBSD-5.1.RC4, for example)

Can we start with a slight relaxation - lets have 5.0 === 5.0.x == 5.0RCx?