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

[Julien Laffaye]

On 9/1/2012 7:43 PM, Tijl Coosemans 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@ on his bsdconfig scripts, so yes in
>> anycase the bsdinstaller will end up with a boostrap dialog to install pkgng.
> Something else I thought of, you can't assume there's a working internet
> connection during installation. And also, even if there is a connection, can
> you guarantee that the downloaded pkg supports the packages on the dvd for
> the lifetime of the release?
The packages set included on the dvd will probably be EOLed before the 
lifetime of the release.
> I really think you should just do vendor imports of pkg in base and include
> pkg on the dvd. There's no bootstrap problem then and the dvd is nicely
> self-contained. It also shouldn't be a problem to keep the official pkg repo
> for that release compatible with it. Just keep using the same version of pkg
> to create the repo.
>
> You've been able to develop and introduce pkgng without breaking older
> releases which shows having pkg tools tied to releases was never a problem.
> All that was needed was to move pkg development outside base. You should be
> able to do pkg 2.0 development in the same way. And when that new version
> is ready you import betas and release candidates in head and use current
> users as testers, just like is done with clang.
>
> In this scenario the ports tree needs to keep support for older releases,
> but that's a consequence of the fact that there's only one ports tree for
> all releases. Somewhere in between the ports and the various releases there
> has to be some form encapsulation, not just for pkg, but for all the tools
> used by the ports tree. Given how the ports tree currently encapsulates
> both the old and new pkg tools I don't see how supporting multiple versions
> of pkgng would be a problem because presumably the difference between pkgng
> versions is going to be much smaller than the difference between the old
> and new tools.
>