pkgng suggestion: renaming /usr/sbin/pkg to
jilles at stack.nl
Sat Sep 1 22:34:11 UTC 2012
On Sat, Sep 01, 2012 at 08:40:03PM +0100, Matthew Seaman 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.
One restriction is that the old pkg should be able to detect the new pkg
package in the repository. If not, users of an old version will have to
install the new pkg manually.
This restriction is much weaker than requiring an upgrade using the old
pkg, mainly because pkg does not depend on anything else. All other
packages can use features and bugfixes in the new pkg and need not
carry around workarounds for years.
If the base system is also managed by pkg, which is currently not the
case, the assumption that the pkg package does not depend on anything
may no longer hold. It might depend on a new libc in the new base
system, for example.
> 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.
More information about the freebsd-current