Re: Making it easier to get and use pkgsrc

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

David Brownlee <abs%netbsd.org@localhost> writes:

> On 12 December 2010 01:19, Aleksej Saushev <asau%inbox.ru@localhost> wrote:
>> 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
>
> Most of the Linux distributions seem to manage this, and they're high
> enough profile that someone would be expected to fund a squad of
> attack lawyers if they have it wrong.
>
> Some of their solutions may have involved financial or other arrangements
> which are not practical for NetBSD, but it is possible.

Then someone should look at how this problem is solved in those distributions.

> I don't see this as a zero sum game - we should be able to provide a
> usable desktop, potentially missing a few codecs (because even installing
> everything from pkgsrc from source right now NetBSD is not exactly
> the video desktop solution of choice), entirely from binary packages,
> providing the full flexibility for the 'build everything from source' camp.

Unless something has changed, you are not allowed to distribute mplayer itself,
it isn't matter of missing codecs.

> Theoretically the hybrid bin-install user should just be able to take
> advantage of both - a good set of binary packages under known URLs
> and an easy way to get pkgsrc source tree setup.

I don't see anything theoretical here, I used this approach when I had
to get system up and running fast. This was long ago though, that's why
I'm asking if the support degraded.

By the way I want to point that if this went unnoticed, then we don't
have enough users interested in binary packages. Thus all those whines
we hear now relate to theoretical considerations rather than anything
practical. If we do have interested parties, they should come with some
testable arguments.

>> 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.
>
> Yes, a number of people have put in a lot of time and effort over many
> year to be providing the binary packages we currently have. I think
> things could be helped by more resources and potentially better ordering
> and selection of what binary packages to build first. I think someone has
> already started a separate thread on that (possibly on another list) so I'd
> prefer to leave that there :)

We discussed that on pkgsrcCon.
We don't have published statistics on packages used.
As far as I understand it, most users are unaware that we gather it at all.

>>>>>> - 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.
>
> Maybe NetBSD should ship with a set of tools which know enough to install
> the binary pkg_install packages. Either a user is working with binary 
> packages,
> in which case the pkg_install binary packages should be living in the same
> location as the packages they are trying to install, or they're using pkgsrc 
> src
> in which case they can call bootstrap.
>
> Alternatively (and potentially less controversial), we have prior art
> in mailer.conf,
> or even pkg_alternatives - install the system pkg_install in
> /usr/libexec and have
> wrappers which know to call the system or pkgsrc-installed versions...

Wrappers are interesting idea.


-- 
HE CE3OH...