Re: Making it easier to get and use pkgsrc

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 11.12.2010 23:28, Aleksej Saushev wrote:
>> 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?

Fetch a whole archive and untar it just to run make bin-install in the
end? Sounds like overkill...

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

okay.

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

Depends on the vision of what pkgsrc "is". From my PoV, pkgsrc is the
source tarball, that contains the hierarchy of Makefiles needed to build
the 10000+ packages found within. The package management system is
rather pkg_install.

When I mean "using pkgsrc directly", I mean "using the Makefiles." If
you consider pkg_install to be "pkgsrc", fine with me. What would be
interesting is a tool to query pkg_summary information on a repo
remotely, like pkgin somewhat. One use case I can imagine is querying
information on a binary repo to know if package foo was built for
version bar on platform xyz. But we digress.

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

There are persons running bulk builds on a regular basis. But that's a
question left for another thread :)

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

Then why not make USE_DESTDIR=yes the default? Just asking.

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

Hmm, interesting. Bootstrapping allows variations, however you would
have to integrate that step in sysinst somehow; so we are back to square
1, e.g. "providing easy access to pkgsrc packages during or just after
OS install."

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

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost