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. 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? 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.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:30 UTC