Jonathan Edwards wrote:
On Aug 25, 2009, at 6:03 PM, johan...@sun.com wrote:
The system has to be servicable in addition to being manageable.
After reading the posts in this discussion, nobody in favor or
no-deps or force has been able to articulate why this would be
necessary if dependencies are kept correctly in package metadata.
it's this exact assumption that's being challenged, and i think the
response essentially boils down to "not our problem - the package
creators need to 'correctly' structure and define their dependencies" -
(whatever this means) .. or "file a bug if a package dependency is
'broken'" - (for whatever we take the term broken to mean)
You're challenging the assumption that the system has to be servicable?
no silly .. i mean the assumption that "dependencies are kept
'correctly' in package metadata" .. also assuming the notion that
"correct dependencies" exist
Isn't this more or less arguing against the idea of packaging software
at all? Beyond tarball extraction, what does a packaging system provide
except dependency management? We could provide a centralized location of
tar balls with the same features auxiliary features (search, contents,
info, etc...), and that wouldn't really be a packaging system.
Files are included in the same package because there are dependency
relationships between them that are needed to provide a set of
functionality. I don't think you're suggesting that we should just
provide users a interface of individual files to download and splat on
their system. Why are the implicit dependencies (expressed by being
members of the same package) any more or less valid than the explicit
ones (expressed by the depend action)?
pkgrecv --nodeps and re-publishing in a local repository is an idea
and pretty simple to implement, but this doesn't necessarily help if
you want to quickly remove something buried under 3 layers of
dependencies and test your own dependencies.. agreed that this is
typically done as part of a quick troubleshooting exercise (ie: remove
this package, re-add this package) or developer exercise (eg: "let me
make sure the system is forced to used my libraries instead the ones
provided by this dependency") instead of a proper *modification of
installed packages invalidates your support agreement* type of
exercise .. but i've been in this boat a number of times, and i really
dislike having to work around the installation tools to get the system
to look like i'd want it to ..
You'll have to clarify why this solution doesn't help in this situation.
If what you want to do is test whether your libraries are being used,
and you're unwilling to publish your own package, why not just splat the
files in place? That's essentially what --force or --no-deps will do any
way? Why do you need the packaging system to do the "cp" commands for you?
don't get me wrong - i'm not saying that --force and --no-deps is the
only solution to the problem .. and yes i've met my fair share of
cowboy administrators that systematically hose their systems with this
(of course they also tend to figure out the correct order later, and
quickly rebuild if there's a problem .. so it can be less of a concern
than you might think) .. i'd just like to propose a --zforce option
that checks to make sure you're on a zfs root, automatically snapshots
the current config, applies the changes unconditionally while also
logging the state of the system to document what you've done .. i'd
also like to propose a package map tool that details the topography of
the package dependency landscape - i believe it'll make conversations
like this much easier to have, as well as easily display dependencies
or possible options for the administrator before they commit to
something they may not have wanted in the first place.
You can do the equivalent of --zforce today. Writing a little tool to
look at the files from a manifest, pull only those out, and splat them
on disk shouldn't be difficult. Do a zfs snapshot, run your tool, and
you're done. Why a tool that we know will lead to breakage needs to live
in the packaging tool is something that still hasn't been articulated
except saying that because other systems do it, we should too. As others
have mentioned, a concrete example of a time when you actually had to do
this on IPS would make for a much more compelling discussion, as would
explaining why the package republishing solution isn't satisfactory
other than it having more than one step (which could of course become
one step with the appropriate tooling and wrappers).
I like the idea of a package map tool. I have my doubts that it will
jump to the top of any current priority lists, but I could be wrong. I'd
love to hear some ideas about how such a tool would be practically used
(as justifications for why we should spend time on that instead of other
things), or even better see a community member pick up that project and
run with it. (As a side note, I suspect the real use would be to have
that info graphed at a sub-package level, or with dependencies tagged on
a per file basis. It might suggest some package refactorings which would
otherwise be difficult to tease apart.)
Brock
just a thought
Jonathan
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
