Peter Tribble wrote:
>> 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.
>
> That's an assertion that some of us regard as non-obvious.
>
Some notable issues include:
* The current toolset has no support for automatic dependency
generation or verification.
* Any significant change to existing packaging boundaries requires
manual logging of any changes in pkghistory file to get upgrade to work.
* Changing packages, adding new ones, etc, is not possible in patch,
You are familiar w/ using svr4 packaging for applications; to deliver
a modern operating system w/ it is something else again. It's very
hands-on and requires much manual effort to prevent, catch and
repair the inevitable mistakes.
>> - lack of support for dependency-based retrieval during package
>> installation,
>
> Errm. pkg-get has done this for years.
Yes... and it's not part of pkgadd. It's layered on top, and often gets
it wrong such that I must manually update some packages first before
it will update the one I want.
>
>> - 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.
>
But the difficulty inherent in maintaining dependencies w/ our current
packaging system led directly to the overly coarse sizes.
>> - lack of versioning and control over change,
>
> Again, I regard this as having more to do with package
> contents that the tools.
>
>> - forced interactivity,
>
> Forced? The current system *allows* interaction.
Sigh.... it's all wrong.
>
>> - 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.
>
The simple fact is that the functionality of svr4 packaging is
inadequate to handle linked images (diskless, zones, etc).
Rewriting zones and xVM code to extend the packaging system implementation
makes much less sense than trying to extend packaging to deal w/
zones. Designing the system to cope w/ linked
images & filtering from the beginning helps this a lot.
> And patching performance is pretty abysmal in essentially
> all contexts, and most of it has zip to do with the underlying
> packaging technology.
>
Aside from the reliance on scripting, the contents file, the need
to boot zones for safety when patching them since packaging
scripts aren't safe to run in zone contexts.
>> - lack of safety,
>
> Please define the term!
>
See above...
>> - high developer costs around package and patch creation and
>> maintenance,
>>
>> - lack of support for unprivileged package and patch
>> installation,
>
> It sorta works. That's a minor implementation detail, really.
>
>> - lack of awareness of ZFS and smf(5),
>
> Why would a software administration need to be that aware of these
> technologies?
Well, explore for a moment how today's carefully hand-crafted patches
construct a backout
patch that undoes the application of that patch, and then explore how
much simpler that
is w/ ZFS.
>>
>> 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 if changes?
* developers want user level install & management of multiple
installations of the same packages
* maintainers want automated update generation instead of hand-crafted
patches
* automatic dependency generation on publication, and automatic
following on download
* repository-based rather than file/directory based to permit continuous
updating model
>> More controversially, the project, in an attempt to increase
>> system safety and to reduce developer burden, removes the notion
>> of arbitrary context scripting from packaging. (This removal
>> means that the legacy packaging system must remain on the system
>> for long-term compatibility.) Empirical evidence from the
>> prototype phase has so far borne out this decision.
>
> 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?
>
> And that users and administrators are going to have to know - and use
> - both (potentially incompatible) systems for that period?
If admins don't wish to install any old packages, or they convert them,
they can completely
ignore the legacy mechanisms. Given that we'll support S10 for many,
many years,
the current packaging tools will be supported as well.
They won't be used to deliver Sun software for Solaris, however...
>> 4240078 pkgadd should not allow an intel package to install on Sparc and
>> visa-ve
>
> Sometimes you want to do this. I'm not sure you can simply
> say this is always wrong.
>
Sure you can - it's always wrong to cross architectures on the live
image; it's never ok to install a sparc binary in /usr/bin on a x86 machine.
(Ignoring emulation environments...).
>> 4385316 RFE Support pkgadd of clusters
>
> Yep, we really need this.
>
Already in IPS.
> None of the above are particularly exciting or difficult. It's perhaps
> a source of embarrassment as to why some obvious pieces of
> functionality haven't been fixed in 15 years.
>
yes.. part of the problem here is that the design of the packaging
system is a series of hacks and kludges. Attempts to address even
the simplest problems often foundered on lots of "implementation
as architecture" issues.
> 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.
>
The list here was by no means inclusive. For fun, consider the following:
* Explore the issues involved in adding a needed package to a
minimized, patched system today.
* Describe the problems inherent in applying patches that are
not compatible w/ the currently running kernel/userland.
* describe what a developer must do to insure that patching
and packaging work correctly if two packages exchange files.
>> 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?
>
You want zoneadm to start parsing patch README files?
> BUI? Ah, Browser UI. Yuk!
Don't worry;
pkg install openoffice
does exactly what you'd think.
>>
>> 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.
>
Why is the file format *the* critical factor? I would think that
file formats are really seconary, if not tertiary, since only the
packaging system deals with this. If you mean how you put
packages into the system and how to get them out, that's not
how it works.
>> 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.
>
Broken to whom? If you meant that an administrator can
figure out that svr4 packaging isn't the native way OpenSolaris Next
gets delivered, that's true. Package dependencies will work
for legacy package deliveries.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
