[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Making it easier to get and use pkgsrc
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.
Oh hai :o
> 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
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).
> 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)
> - 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). 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.
> - 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
> Some other random *potential* cleanup
> - Move PKG_DBDIR under PREFIX
Should be, IMHO.
> - Default to DEPENDS_TARGET=package-install and
I already hear someone complaining in the background :o
> - 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
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)
Main Index |
Thread Index |