* Peter Tribble <[EMAIL PROTECTED]> [2008-02-29 19:56]:
> > It is asserted that the refactoring and renaming of the existing
> > package graph is not achievable with reasonable cost and
> > duration with the existing packaging/patching/installation
> > software. It is assumed that compatibility with the existing
> > graph can be preserved, to support the earlier assumption on
> > preserving legacy package operations.
>
> That's an assertion that some of us regard as non-obvious.
>
> Indeed, it is entirely unclear to me how the package graph
> is dependent on the toolset used by user and administrators.
That's not the only toolset in play. The package history and various
"tocs" in the installer are limited in their ability to deal with the
amount of change required.
> > - lack of support for dependency-based retrieval during package
> > installation,
>
> Errm. pkg-get has done this for years.
So have other systems; please expand your point. I can add "from
multiple repositories", if you like.
> > - coarse and incorrect dependencies, limiting use for
> > construction of appliances or other specific-purpose systems,
>
> A deficit in the package metadata, not in the toolset.
>
> > - lack of versioning and control over change,
>
> Again, I regard this as having more to do with package
> contents that the tools.
That's fine. I disagree that the problems can be solved only with
additional or corrected metadata.
> > - forced interactivity,
>
> Forced? The current system *allows* interaction.
The current system *defaults* to interaction, and has features to
encourage developers to have interactive operations. Based on my
discussions with admins, this placed the burden on the wrong party
(the admin). Interactivity is for installers, not packages.
> > - integration with virtualized systems, particularly patching
> > performance,
>
> This is one area where I feel there was a huge mistake - that
> packaging was bent (broken) to fit around zones, rather than
> leaving packaging to just -well - package, and getting zones
> to understand packaging. This is one mistake we shouldn't
> aim to repeat.
You have to go further on this point to convince me: the architecture
in place is "packaging supports zones and diskless". That sets an
expectation, that seems easier to meet.
Maybe a specific suggestion about how zones should understand
packaging would help.
> > - lack of safety,
>
> Please define the term!
I'll expand this. This point is about the difficulty and unneeded
degrees of freedom introduced by the permitted scripting.
> > - lack of support for unprivileged package and patch
> > installation,
>
> It sorta works. That's a minor implementation detail, really.
Disagree.
> > - lack of awareness of ZFS and smf(5),
>
> Why would a software administration need to be that aware of these
> technologies?
A big difference that I'm noticing in these discussions is that only
the people building distributions worry about packaging kernels,
drivers, and early system services. If you're focused on packages
that deliver software that operates later (or after) system
initialization, you might not care about some specific issues. smf(5)
awareness is needed to make early system services install correctly;
it also provides a means of identifying package dependencies that
isn't easily determinable from the object code.
ZFS awareness is so we can have rollback with filesystem assistance.
> > 3.2. Market/Requester:
> >
> > Distribution providers and software content providers utilizing
> > the legacy packaging system have requested substantial changes
> > to achieve greater control over maintenance costs and to
> > increase development efficiencies.
>
> Now, what sort of changes?
>
> > Various customers of the historical Solaris release have asked
> > for substantial capabilities not present in the legacy packaging
> > system.
>
> I've asked - over and over - for changes. I'm fairly sure they're not
> what you're planning to deliver in this project.
>
> Again, what sort of changes have been requested?
The list of shortcomings I gave is my distillation of the requests
I've collected. Some of the requests come from large sites, some from
small sites, some from longtime Solaris/OpenSolaris admins, some from
admins coming to OpenSolaris from other platforms.
(That's why I agree with some of your points, and not with others...)
> Now, to be absolutely clear here: you're saying that you anticipate
> that future Solaris (OpenSolaris) releases must supply and support
> both the shiny new system and the crufty old system for an extended
> period - 10 years or so?
Yes.
> And that users and administrators are going to have to know - and use
> - both (potentially incompatible) systems for that period?
Not necessarily. That's an implementation question--we could all
decide that
pkg install /path/to/datastream/or/directory/package
invokes pkgadd(1M); that pkg list has states for old packages; and
that pkg uninstall does pkgrm(1M).
There are reasons to do this; there are reasons not to.
> Now, why can't these problems with the current system be fixed?
> It wouldn't take long, and could easily be backported to all
> currently supported releases allowing all users and customers to
> benefit.
Because these problems aren't *all* of the problems--it's a
selection of bugs. Fixing these (or even a larger list) wouldn't
satisfy all of the needs. And I disagree strongly with your
assessment of the suitability/maintainability of the System V
packaging code.
> > 4.3. In Scope:
> >
> > Package-service delivery and containment relationships.
> >
> > Package installation behaviour in virtualized environments.
>
> Why is it packaging's problem, as opposed to the virtualization
> technology's problem?
Already answered.
> > 4.5. Interfaces:
> >
> > pkg(5) will present a substantial set of new and modified interfaces
> > to the core system. In particular, documented definitions of
> >
> > - retrieval client CLI,
> >
> > - publication client CLI,
> >
> > - administrative and server CLIs,
> >
> > - client metadata representations,
> >
> > - server metadata representations,
> >
> > - retrieval and publication protocol operations,
> >
> > - a dynamic language API,
> >
> > - package metadata conventions,
> >
> > - available package constituents ("actions"), and
> >
> > - package naming and versioning conventions,
> >
> > will be presented as interfaces introduced by this project.
>
> One important aspect that is still missing is a definition of
> a package file format. For widespread adoption, this is *the*
> crucial factor.
I'll add it to this list. It's mentioned at the top of 4.1.
> > It is possible that some of the nominally private interfaces
> > associated with legacy packaging will be affected; at a minimum,
> > files previously delivered via legacy packaging will no longer
> > be tracked by the legacy system. This outcome could result in a
> > correctly functioning system that presents very differently in
> > terms of file-package membership when interrogated using the
> > legacy packaging API.
>
> I'm worried again - this sounds to me that the system will
> likely appear to be broken.
Although we can handle some behaviours (during that compatibility
discussion in architectural review), this project will break "grep
file /var/sadm/install/contents" as an always reliable, although
undocumented, means of determining file-package membership.
Thanks for the feedback.
- Stephen
--
[EMAIL PROTECTED] http://blogs.sun.com/sch/
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
