On Aug 25, 2009, at 10:00 PM, Brock Pytlik wrote:
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?
nope .. it's a form of protection against the idea that package
creators will *always* "do the correct thing"(tm) and that defined
package dependencies are *always* absolutely correct regardless of
what an administrator might know about the system he's trying to
install .. nobody's saying that we should do away with dependencies ..
just define a way to over-ride them if necessary.
Beyond tarball extraction, what does a packaging system provide
except dependency management?
well let's see .. off the top of my head:
* bulk file tracking for install/uninstall
* fine tuning configuration files (ie: preinstall/postinstall)
* file modification tracking
* checksumming, discrepancy tracking
* patching, repairing, etc
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.
why not? ever seen the slackware installer? .. not necessarily as
feature rich as some of the others out there, but it can do the job ..
tag a tar ball or cpio archive with some meta information, store the
installation details in a database of some sort - and you could
realistically do some dependency matching in an a posteriori fashion
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)?
perhaps it might make more sense to separate associations from
dependencies .. files are often included in the same package because
they might be associated with a particular functional definition and
form associations with the package definition .. i wouldn't
necessarily say that "cp" is dependent on "tip" or that there is a
dependency relationship between them, but i would say that both "cp"
and "tip" are associated with what's been defined in the "core
Solaris" package SUNWcs. To call them dependencies (whether required,
optional, or incorporate) simply because they fall within the same
package framework is a bit of a misnomer.
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?
in a word - so i can easily track them and back them out when i'm
done .. setting up an entire repository to roll a whole distribution
to work around a few broken dependency digraphs (note: broken as it
pertains to the plans of the administrator) - seems a little like
overkill in my opinion .. particularly if all i want to do is to
temporarily clobber a known package a few layers deep (eg: zlib,
openssl, etc)
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
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
