On Sat, Sep 1, 2012 at 12:40 PM, Matthew Seaman <matt...@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@, 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,
-Garrett
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
