GitXplorerGitXplorer
m

apm

public
14 stars
0 forks
1 issues

Commits

List of commits on branch master.
Unverified
61c7e0013472c1dfe4177c445a30fcd1794da8d1

[fix] Add error handling

mmmalecki committed 11 years ago
Unverified
3f31ad7dc927a9cfbd5c8cfbdbb7cb81e68c792f

[fix] Fix linking with already installed packages

mmmalecki committed 11 years ago
Unverified
449926051ed31730fda5f924053269fab3b818b3

[fix] Actual reading of installed packages

mmmalecki committed 11 years ago
Unverified
bc13ca05b5f8ae752fd872de90932d9c02ef391f

[api] Add linking

mmmalecki committed 11 years ago
Unverified
03ffff68051b88cf8b10a6223d0351479efcaad0

[refactor] Move linking out to a separate file

mmmalecki committed 11 years ago
Unverified
fdb0570318967057ce839efdbc22d47d8b83a2f2

[fix] Add missing `tmpdir.js`

mmmalecki committed 11 years ago

README

The README file for this repository.

apm

Anarchy Package Manager - the package manager for AnarchyOS.

Paths

Tricky part is how to support "legacy" applications. This means that we have to provide at least:

  • binaries at /usr/local/bin and /usr/local/sbin
  • libraries at /usr/local/lib
  • includes at /usr/local/include

A generic solution to that would be to make a package list its own links, relative to prefix (let's stay with /usr/local?).

So I thought up this packet.json format:

{
  "links": {
    "bin/me": "bin/me",
    "sbin/me-admin": "bin/me-admin",
    "lib/libme.so": "libme.so",
    "include/me.h": "include/me.h"
  }
}

This would create links at specified locations, pointing to the installed version. User would be able to change them with <p-m> select <packet>@<version> (this'd relink) or drop into the right subshell with <p-m> use <packet>@<version>.

Dependencies

To ensure that dependencies are satisfied during the compilation, we'll simply be able to execute the compilation in a subshell started with <p-m> use <dep>@<version>.

I think this frees us from handling recursive dependency trees. Imagine this kind of dependency tree:

  • a depends on b@1.0.0 and c@1.0.0
  • b depends on d@1.1.0
  • c depends on d@1.2.0

So, we'd compile b after dropping to a subshell with d@1.1.0 and then c, after dropping it to a subshell with d@1.2.0. Disclaimer: I have no idea if this won't cause some weird linking conflicts.

Database

The database could live anywhere. Format could be similar to:

me
| - 1.0.0
             | - packet.json
             | - bin/me
             | - ...
| - 1.0.1
             | - packet.json
             | - bin/me
             | - ...