Re: Making it easier to get and use pkgsrc

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

Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost> writes:

> On 11.12.2010 21:14, David Brownlee wrote:
>> 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.
>
> 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).

You don't have only two alternatives. There's "make bin-install" that
combines both approaches. I'm asking again, has it degraded? Is there
anyone who could test it at least?

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

_Not_ "pkgsrc-release" since technically it isn't release,
it is snapshot of a branch.

>> - 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).
>
> IMHO, on the longer run, the binary package approach has to be
> envisioned, because it allows fast installation procedure, is still very
> close to pkgsrc source, and has additional information provided via
> pkg_summary metadata (which cannot be obtained when using pkgsrc
> directly, for obvious reasons).

Why not?

> For example, build summaries are helpful
> to know whether a package can get built successfully for a given OS +
> architecture, where source pkgsrc cannot expose that easily.
>
> Yes, this needs cooperation to build up binary repositories; nothing is
> really free down there.

This raises very important question. Who is going to do this?

>> - 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
>
> I already hear someone complaining in the background :o

It is much better to default to USE_DESTDIR=yes than to
DEPENDS_TARGET=package-install

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

If you really want to perform cleanup, kick pkg* tools out of base system.

It is really annoying that you have to watch that you use those that are
under /usr/pkg because pkgsrc may have and may need newer tools installed
(and pkgsrc is more up-to-date than NetBSD). It isn't hard to install
pkgsrc bootstrap kit at sysinst time, and updating pkg* tools as part of
pkgsrc is much easier than as part of base system.

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

This is cosmetic change which may be dangerous.


-- 
HE CE3OH...