#ident "@(#)issues 1.14 08/08/07 SAC" Pre-Inception Meeting July 30, 2008: dwc-0 The fact that pkg rollback only works on ZFS and that ZFS does not conform to standards seems to limit the ability to deploy to US Government, financial, and telephony markets. (t-arc-preincept-outline-jul-2008.pdf page 3) dwc-1 Cutesy option strings (e.g., "strawberry" as a file action "preserve" attribute value) make this seem more like a toy than a serious project. Why not something like "ignorenew" that has obvious meaning? (pkg.5.txt line 102) ged-1 Is there just a single master catalog? If multiple catalogs are supported, how are disagreements between catalogs handled? ged-2 Is metadata signed? How do enterprises manage multiple "authorities" for the package? djr-1 Is IPS bittorerent friendly? (discussed) Answer: it isn't anti-bittorent djr-2 Can IPS+SVR4 coexist on the system at the same time? (discussed) Answer: yes djr-3 Can package authorities be discovered rather than configured? djr-4 Is there a special protocol that IPS uses for doing updates to make them more efficient? (discussed) Answer: individual files from inside a package are transferred via http. djr-5 If multiple catalogues/depots are available, how does IPS choose which one to use if they are publishing conflicting information? djr-6 Does the single package with multiple binary objects for different CPU architectures scale well? (discussed) Answer: This isn't considered to be a concern. djr-7 Can a depot/repository push files out to a client? (discussed) djr-8 Can IPS deliver files with specific filesystem (eg ZFS) attributes? (discussed) Answer: not yet, Stephen to investigate. djr-9 Can a package require a reboot after being installed? (discussed) Answer: no. Installation of files is done using ZFS in a manner in which new object files do not interfere with the running system. djr-10 Does this project deliver tools to create IPS packages? (discussed) Answer: yes. pkgsend is that tool. jmp-0.1 What "ARC behaviors" might be/should be impacted by this case? My areas of concern are the potential impact to the Release Taxonomy/Binding, the level of ARC review required for things bound for the different OpenSolaris/Sun repositories... jmp-0.2 Namespace issues for depots, packages and installed bits. PSARC/1991/061 says that a given "/$path/$file" can only be delivered by one package; having two packages deliver, say, /usr/bin/ls is forbidden. Obviously, the package that delivers ls can have multiple versioned instances in a depot without breaking this rule, but what happens across depots? Upleveling, who "owns" the filesystem(5) namespaces in a given distro? Use case example: pkg.opensolaris.org has a "gnu binutils" package that installs into some mix of /usr/gnu and /usr/bin. pkg.roland.project.opensolaris.org, pkg.blastwave.org and pkg.gnu,org also have their own "gnu binutils" packages. All these authorities will make different choices relating to the use of /usr/gnu. What are the expectations/requirements/... with respect to package names, installation paths, ..., ..., ...? Who gets to install in /usr/bin (or /usr/lib), and how is the shared namespace managed? Do we end up with /opt/csw/*, /opt/gnu/* and /opt/roland/*? If not, how do we manage the stacks of mutually incompatible dependencies that will inevitably arise? jmp-1 A picture is worth a thousand words. One that shows the relationships between authorities, repositories, depots, packages, mirrors, proxys, images, the various pkg commands, the on-disk format stuff, manifests, metadata, the user's source tree, build system, and the "ready to package" binaries would be a tremendous aid to understanding this case. gcs-1 What are the implications of disallowing scripting? The discussion partially addressed this question: it's clear that a rich set of actions is required; what's not so clear yet (at least to me) is whether there will be a significant residue of things that the actions should handle, but don't. gcs-2 How feasible, in practical terms, is a strategy that depends on customer acceptance of IPS on non-Solaris platforms? Discussed: Not the project team's problem, but something that product teams intending to use IPS in this way need to explore and understand. gcs-3 Similarity of installation process with SCM: is any leverage possible? Discussion: The project team agreed that there are parallels; I suggested that it might be worthwhile having documentation explicitly note them, as an aid to help users understand the installation event sequence. gcs-4 Interaction with the build system to allow principled dependency checks. Discussion: We will want to understand the interfaces that IPS supplies and depends on here, to help us assess the extensibility and modularity of the dependency checking subsystem. gcs-5a What are the interfaces to the assembly process? (How will RTIs, etc. be impacted? gcs-5b What are the implications of this project (especially its support for multiple repositories) for process-related things like release bindings? Both parts of this question are related to issue jmp-0. I strongly suspect that we'll uncover/create the answers to all of them over time, as we collectively become more familiar with IPS and integrate it more tightly into our procedures. But the discovery process should be proactive rather than reactive. gcs-6 Interactions of transactions and dependency analysis -- sounds complex; will want more flesh in next round of materials. gcs-7 Boundary between laying down bits and activating them -- want more clarity/detail. gcs-8 Need to explore the tagging facility and its potential relation to architectural classification of installable artifacts. gcs-9 Discussion for 2008/507 [OpenLDAP] has indicated that IPS allocates user and group entries on the target system on demand. What are the implications of this behavior? Can complications arise from mismatches in the numeric values of users or groups with the same name on different systems?