Date: Tue, 14 Jun 2016 22:48:39 +0300 From: Arto Pekkanen <isoa@kapsi.fi> To: freebsd-pkgbase@freebsd.org Subject: A suggestion: implement namespaces to isolate package sets Message-ID: <2b19824ed3653d4f08e9ca90298cc547@kapsi.fi>
next in thread | raw e-mail | index | archive | help
I just joined the mailing lists, so I haven't been able to reply to the earlier threads. In https://lists.freebsd.org/pipermail/freebsd-pkgbase/2016-March/000032.html it was mentioned > 2) At present, running 'pkg delete -a' will implicitly remove the > 'FreeBSD-*' packages, leaving the system in an unusable state. There > are valid use cases for removing all packages, such as test chroot(8) > or jail(8) environments, so a solution to avoid accidental foot > shooting is still being investigated The easiest way to prevent accidents is to implement a namespacing scheme. That is, each package can define a namespace in which it resides. Package would only be acted upon if, and only if, both it's name and namespace match the package selection criteria of the operation. If a package would not define a namespace, it would be considered part of the "default" or "undefined" namespace. This "default" namespace would, by default, mostly consist of packages built from /usr/ports and installed in /usr/local prefix. When invoking the pkg tools, the namespace would have to be explicitly declared in each context. My suggestion on how to do this is to declare namespaces in the form of //<namespace>. A package glob within a namespace would be declared in the form of //<namespace>/<glob>. NOTE: I think there is no need to panic about this namespacing scheme getting mixed up with filenames, because pkg utilities either handle name globs for packages from repository (install, remove, query, rquery) or filenames (add), not both at the same time. IF a namespace is declared without a glob, then "*" is assumed. Thus //foo/* would equal //foo IF namespaces are NOT declared for package globs during the invocation of the pkg utilities, the "default" namespaces would be implicitly assumed. Like this: # install zfs stuff from org.freebsd namespace pkg install -r FreeBSD-base //org.freebsd/zfs # remove all packages matching *ssl* from org.freebsd namespace # note: quoted to prevent shell globbing ... you'd do that normally anyway pkg remove "//org.freebsd/*ssl*" # install bash without specifying a namespace # that is, bash would be installed from a repository in which it's namespace is default (or undefined) pkg install bash # this would return error, since no repository has package bash with namespace org.freebsd pkg install //org.freebsd/bash # remove all packages from "default" namespace. # NOTE: this will NOT touch ANY packages from any other namespace, including org.freebsd pkg remove -a # remove all *ssl* packages from "default" namespace # NOTE: does NOT remove, say, base system libssl pkg remove *ssl* # would list all installed packages from "default" namespace pkg info # would list all installed packages from org.freebsd namespaces, ie. the base system packages pkg info //org.freebsd In the examples it is assumed that base system is in repository FreeBSD-base, and that all the base system packages have the org.freebsd namespace. Yeah, I would use reverse domain names as namespaces, that is just the rational thing to do, all things considered. If no namespacing scheme is implemented, then the other options to prevent scenarions like "I accidentally the whole base system" I can think of are ugly kludges; kludges like "protected" or "hidden" package flags. I think in the end we want beautiful solutions, and namespacing gives just that. Besides, no other packaging system I know uses namespaces. Having the namespace option in FreeBSD, even if just for base system packages, would make pkg really cool and different. Also, I am kinda sure there are plenty other applications for having a namespaced package management. PS. typing this from webmail, next messages include my public key, but I haven't got it in this mail yet. -- Arto Pekkanen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2b19824ed3653d4f08e9ca90298cc547>