Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap

From: Chris Rees <utisoft_at_gmail.com>
Date: Fri, 31 Aug 2012 17:02:23 +0100
On 31 August 2012 16:47, Tijl Coosemans <tijl_at_coosemans.org> wrote:
> On 31-08-2012 14:22, Baptiste Daroussin wrote:
>> On Fri, Aug 31, 2012 at 08:10:50AM -0400, John Baldwin wrote:
>>> On Friday, August 31, 2012 5:59:10 am Baptiste Daroussin wrote:
>>>> On Thu, Aug 30, 2012 at 01:02:06PM -1000, Doug Barton wrote:
>>>>> I agree with John on all counts here. Further, the idea of a
>>>>> self-installing package, at least for the pkg stuff itself, addresses
>>>>> the issue that someone else brought up about how to handle installation
>>>>> of pkg by the installer for a new system.
>>>>
>>>> I like the idea of also providing a self-installing package, and it seems really
>>>> easy to do, so I'll try to see what I can do in this area I'll wrote a PoC in 5
>>>> minutes which looks pretty good, this could also be a very simple and easy way
>>>> to integrate into bsdinstaller.
>>>>
>>>> I'll do work in that direction.
>>>>
>>>> Still it doesn't solve the problem of boostrapping pkgng in a fresh new box,
>>>> because the user may not know where to download the pkg-setup.sh.
>>>
>>> I do think that is something bsdinstall should be able to handle, and I would
>>> certainly want bsdinstall to include a dialog that says "do you want to install
>>> the package manager?"
>>
>> Of course this is being worked on by dteske_at_ on his bsdconfig scripts, so yes in
>> anycase the bsdinstaller will end up with a boostrap dialog to install pkgng.
>
> ...using a mechanism that will be supported for the lifetime of the release.
>
> My concern is that the problem with the pkg tools was never that they were
> tied to FreeBSD releases. If that were true then you cannot accept the
> bootstrap solution above because it has exactly the same "problems".
>
> The problem in my opinion was simply that the source code lived in src where
> ports developers didn't have good access to it. And the solution for that is
> to turn pkg development into a third party project and import that into base
> from time to time. There can also be a port for it so people can use more
> recent versions if they want to. That's the situation for several third
> party tools in base.
>
> Given that the ports tree is currently supporting both the old and new pkg
> tools I don't think it would be a problem for them to support older versions
> of pkgng when the time comes, especially since the database used by pkgng is
> much more flexible and you can execute any sql query on it.

Absolutely not.  This is close to the top reason pkg has been moved to
ports-- it should not be in base, because then we're stuck with
supporting that version for a very long time.

Chris
Received on Fri Aug 31 2012 - 14:02:55 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:30 UTC