On Sat, Sep 1, 2012 at 12:40 PM, Matthew Seaman <matthew_at_freebsd.org> wrote: > On 01/09/2012 18:43, Tijl Coosemans wrote: >> 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. > > New functionality already in the process of development will entail > making non-backwards compatible changes to the DB schema. If we're tied > to supporting a version of pkgng bundled with a release, that's going to > make rolling out such changes much harder. On the other hand, if pkgng > is in ports, then we can release a new version and simultaneously > publish new package sets (incorporating the update to pkgng) from the > repositories which will have been built using the updated DB schema. > > The ports tree doesn't track the versioning of the base system, and it > makes perfect sense to me that tools for dealing with the ports should > follow changes to ports rather than changes to the base. Again, this is part of the reason why I suggested multiple release trains. Although it's more painful for bapt_at_, et all, it's ultimately what would need to be done in order for pkgng to be packaged with a release or set of releases. I would be happy to assist with this -- it's the least I could do. Thanks, -GarrettReceived on Sat Sep 01 2012 - 17:59:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:30 UTC