[arch-general] Ye Olde Package Manager

[C Anthony Risinger]

On Thu, Jan 13, 2011 at 12:31 AM, David C. Rankin
<drankinatty at suddenlinkmail.com> wrote:
> On 01/12/2011 10:51 PM, C Anthony Risinger wrote:
>>
>> I want new thoughts about what the meaning of a package is ... and how
>> it can be better represented for derivation from it's integrals;
>> source code and user state.  the tarball has served us well for a long
>> time, but ... in the now-time of cheap encryption, distributed clouds,
>> parallel peers and ...
>
> So you want to talk calculus do you? Perhaps the method of strained time and
> strained coordinates would would give a better approximation? Poincare-Linstedt
> maybe?

ehm, it was more a play on words; but yeah, a package is a living
target, derived from and bound to higher order constraints.  they
don't need to be the static, rigid snapshots they currently are, but
it requires a different way of thinking about what a package is, and
the purpose it fulfills.

> Seriously, I've been very impressed with Arch packaging compared to rpm or deb.
> KISS has served Arch well.

oh sure it works well enough, else i probably wouldn't be here right
now having this conversation... but that doesn't mean there is
anything novel or even remotely interesting about pacman.  they all
suck equally IMO, but if your willing to part with the various
management features pacman drops and the complexities it adds to be
"KISS", then it can usually drag you where you want to be.

if you think a package's purpose is to simply add some files to your
system in a revocable way then you've missed the point; computers work
for us.  _i_ chose to install that package for a purpose; _i_ want the
computer to assume some initial state, any react to system events.
_i_ don't really give a !@#$ about files, how it accomplishes my
directive, or what the computer thinks it wants.

> The only thoughts I've had on the issue were with the
> gzipped package directory format of the repository indexes, but I don't see
> anything wrong with it. It works as well as it would in a flat file format or in
> some record oriented db format. I'm sure there is a faster way to do it, but I
> haven't noticed any slowness with the current system.

it's less about speed, and more about creating a package structure
that's able to track the source it's derived from, merge with custom
"code sinks"/overlays, and integrate itself with the behavioral
requirements of the target system, as defined by the integrator/user.
it's about creating a structure that is at it's core cross-distro; a
structure with the plasticity to absorb modifications from many
sources, re-configure and trim itself as needed, and acquire the bits
it needs to assume the state asked of it.

> A package in any distro provides the necessary installables along with a way to
> check for conflicts and resolve dependencies. The current packages do that well.

sure, they do it well if, during each release iteration, every little
step has been perfectly spelled out for them by a human "packager",
you don't deviate from the "official" monolithic package pools, and
you never want to do anything interesting or custom.   like i said, a
bulk download + extraction is the part the manager performs ... ie.
brain dead ... the rest of the logic was hand crafted by humans.

> The only differences that I've seen with pacman vs. some of the others were in
> areas of handling or anticipating previously installed config or font files that
> cause rare install failures. But, I think the KISS vs. 'try to anticipate
> everything' argument ways in favor of not radically changing how pacman handles
> these issues -- unless there is just a wealth of unused resources laying around
> to experiment with.

it's not about anticipation of the future/infinity, but rather
guidance from the source, peer heuristics, and input from the
integrator.  technologies like systemd + augeas + git/DVCS + DBUS +
... + ... provide 99% of the tools/foundational ideas, they just need
to be combined in a intelligent way and applied to the problem of
state management.

> Great question. I'd also be interested in what other ideas there are about
> positive and realistic improvement can be made to the current system.

create DBUS bindings to pacman core.  impl the CLI/[GUI] interfaces on
top of common dynamic runtimes like python using those bindings.
leverage a revisioning system for package files instead of tarballs,
even if only locally.  store metadata in a non-relational engine like
couchdb (peer replicaition), or at least something like sqlite, for
sane access.

C Anthony