[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Making it easier to get and use pkgsrc
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.
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.
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.
> 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 :)
>>>>> - 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
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...
Main Index |
Thread Index |