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. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey
signature.asc
Description: OpenPGP digital signature