[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Making it easier to get and use pkgsrc
David Brownlee <abs%netbsd.org@localhost> writes:
> On 11 December 2010 22:28, Aleksej Saushev <asau%inbox.ru@localhost> wrote:
>> Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost> writes:
>>> On 11.12.2010 21:14, David Brownlee wrote:
>>>> - 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.
> but pkgsrc-stable.tgz should be OK?
In my opinion, yes.
>>> 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?
> Would it be possible to park the bulk building binary packages &
> package summary discussions for now?
> They are really important, but if we try to cover too many issues all
> at the same time we're going to end up
> running in (probably slightly antagonistic) circles. If we can focus
> on the pkgsrc 'src' users first and come
> back to the 'bin' users?
>>>> - 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.
> I've been using pkgsrc on Linux and one thing I've found awkward is
> regenerating a bootstrap. Is there an obvious way I've missed?
> (and yes, I think longer term we should look to move the pkg tools out
> of NetBSD, but again I'd like to park that for now as I
> *know* *everyone* will come out of the woodwork to comment on the
> colour of that bikeshed)
Yes, sometimes I feel the need to "tar up" bootstrap kit that's already there.
I think that if we agree that in long term we're going to split pkg
tools from base, we should think about not making the work twice,
one time for pkgsrc tree, another time for pkg tools.
In particular, we should think when pkgsrc tree and pkg tools are installed.
Main Index |
Thread Index |