Need insight on designing a package manager

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

NOTE: Stripping LKML out of the reply path.  Nobody there wants to see this.

Christoph Lameter wrote:
> On Mon, 23 Jan 2006, John Richard Moser wrote:
> 
> 
>>install Sun Java on Debian, I found that clicking "no" on the license
>>permenantly alters the system in ways dpkg can't track and roll back,
>>assuring you can never try to install the package again.
> 
> 
> That is a problem with Sun Java destroying Debians package tracking 
> database?
> 

No, Sun Java did something where it put a piece of information on the
system (like a cookie) to remind itself that I said no, then aborted
install.

dpkg subsiquently decided that sun java failed to install, as the
preinstall script exited with error.  It did not, however, know about
the arbitrary change made to my system; after totally purging all
information about sun java from all dpkg database files et all, Sun Java
still would come back and refuse to even ask me about the license, just
saying I can't install it.

Now, this is an arbitrary system change.  Imagine if it decided to
install a rootkit?  And dpkg just decides, "Oh, it failed to install"?
Do you see a problem?

> 
>>well; policy plug-ins for SELinux are planned, and "meta-native"
>>policies will allow a policy file to have chunks modified based on user
>>query.
> 
> 
> Replacing scripts with meta information that is interpreted has been 
> discussed a few times and I most people involved think this is a good 
> thing.
> 

XML baby.  ;>

Seriously though, a package manager that's actually safe to run is a
core requirement of Project Eva.  Project Coon Fox exists because I need
a dampening method for all those social engineering attacks.  "Here,
install this e-mail worm, it won't hurt you" -- sure.  It wants full
system access, btw, are you sure about this?  What, no?  Nevermind then.

Deployment in Project Eva is going to actually have the output of
Project Coon Fox (i.e. the resultant package manager) configured so that
certain policy settings are specifically banned.  Certain things are the
package manager's job, and you simply don't need access to create,
modify, or delete arbitrary files or kernels in /bin or /boot.

> 
>>Plug-ins will also allow for policy extensions, to understand SELinux
>>and GrSecurity policy files and how to activate them in the system.
>>These policy plug-ins will also translate policies written in a built-in
>>meta-policy language to the native format of the target backend.
> 
> 
> Something like the triggers in UPM? http://uos.graphe.net/upm.html
> 

Very interesting.  Not sure though; it's too early for me to read that
whole big page ;)

Source building is out of my scope, although using 'fakeroot' and an
isolated, restricted user would basically allow building to be done
securely.  Sure we're running random bash scripts again, but they're not
doing anything to the system.  Perhaps I'll look into that in the future.

> 
>>going to handle things is not a good idea.  SQLite was, of course,
>>chosen for performance.  Running a full RDBMS like MySQL or PostGreSQL
>>is out of the question; embedded MySQL is out because it's not object
>>oriented (SQLite lets me sqlite3_open() a database and get a handle to
>>use; I can work on 100 db's if I want, all at once).  Evidently the
>>MySQL folk don't understand that C can be used for object oriented
>>programming; it just doesn't do it in the language, as in C++ or Obj-C.
>>
>>This is one dilema point; I don't know all the information to store in
>>the database.  I'm working on this; could use some help.
> 
> 
> SQLite may still be overkill. Look into the Berkeley DB libraries.
> 

SQLite is a 300k library that depends on pretty much nothing.

bluefox at icebox:~$ ldd /usr/lib/libsqlite3.so.0
        /lib/libsafe.so.2 (0xb7eac000)
        linux-gate.so.1 =>  (0xffffe000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e8c000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d5d000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7d5a000)
        /lib/ld-linux.so.2 (0x80000000)

I hardly think that's overkill.  It's efficient.

> 
>>My current largest dilema is dependency checking.  I want a
>>file-interface dependency model, handled by the install module.  This
>>means looking for either a program /bin/foo or /usr/bin/foo or "InPath
>>foo" (a la autopackage IIRC) and comparing its command line interface;
>>or finding a library in the same way and comparing its API.
> 
> 
> Uhh. That is going to make this whole thing pretty unclean and puts it on 
> the same level of hopelessly unfixable like rpm.
> 

Yeah.  I'd hate to drop back to package-per-package conflict/depends but
it may just be necessary.  If I go that route, then the interoperability
idea amounts to forcing everyone making packages for this package
manager to pretty much use the same package name and version meta-data
schemes.  Ideally it'd be possible to install doom3 or something with
this, without dependency hell.
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD1SB6hDd4aOud5P8RAgieAJ9hehIwDFbHQKQve3en2HlJChkAogCdHnKl
jSRlg0kS+S+5q4UHGVmNXLw=
=hyuE
-----END PGP SIGNATURE-----