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

It isn't.

First of all, desktop user _has_ to build from source. You just can't
live a regular life without building from source. Well... Or you can,
but then someone is breaking the law for you. "bin-install" solves
exactly this problem, with "bin-install" one can install binary packages
when they're available, and build parts unavailable in binary form.

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

There very few such persons, and I heard answers that they don't have
resources for more builds, though builds are automated already.

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

sysinst is more appropriate place to perform initial installation;
if you want to add sets post-sysinst, you are to know what you're doing.

pkgsrc kit is somewhere between base system and packages already,
if you want to change it (to bring better support for binary packages),
it is better to have it in packages _outside_ inflexible base system.

JFYI, pkgsrc already checks for outdated pkg_install in base and
installs _parallel_ package thus shadowing (incompletely!) base tools.


-- 
HE CE3OH...