Stephan Assmus <superstippi@xxxxxx> wrote:
On 2009-04-15 at 09:57:14 [+0200],
Henri Vettenranta <henri.vettenranta@xxxxxx> wrote:
On Mon, 2009-04-13 at 23:19 +0200, Jonas
Sundström wrote:
To host commercial software and keep it safe from
private API breakage, there would have to be some
infrastructure to let commercial entities safely
build and test their software as part of repo
builds without exposing their private source.
If I understood correctly what you're trying to
achieve, I think that's pretty much impossible
by definition.
It does sound like the system should handle the case
of packages not all comming from the same source.
I don´t think there´s anything particular about the
pkgfs that I´ve sketched before which would prevent
combining packages from multiple sources. But a
separate package manager (interfacing the pkgfs
backend) could try to enforce such rules. (If desired,
e.g in an enterprise environment.)
I defintely dont want to lock down anyone´s Haiku.
You might want to package something yourself, or
maybe you recevied a commercial package. Perfectly
reasonable.
But I am hoping for a single good repo though, and
while I don´t see any problems at all with Haiku
developers publishing selfmade packages of native
software, there are very good reasons IMO to be
pushing a shared repo for ported software and for
software with more complex dependencies.
Foreseeing the proliferation of packages from all
kinds of sources, here´s a system that could provide
post-facto dependencies metadata also for packages
missing all information on dependencies or listing
incorrect dependencies:
(Apologies if I´ve written all of this before.
I don´t remember what I´ve elaborated on.)
Any package can be identified by its file checksum.
(A checksum of the raw, uncompressed package image.
(Think .tar, not .tgz. Not necessarily .tar but
something similar.))
A collection of dependency description files would
be created:
- One dep file for each package known to exist.
One could use the package´s checksum as filename.
- Hosted online,
relevant ones cached locally, on your system.
- Submitted by a package´s creator or just
anyone who happened to stumble upon the package.
- Initially copying the dependencies found
in the package (if any are present).
- Each dep file can be updated online at any time,
by a trusted team. Updates are logged. Logs are
provided so clients can check for updates.
- Haiku systems cache dep files for the packages
installed locally and download additional,
relevant dep files and updates to these
when adding/removing/updating packages.
Only at those times.
(Downloading information on actual -package-
updates may very well happen by some kind of
schedule / set interval. Deps and packages
are separate things.)
- Dep file storage and network footprint would
be small.
- Management would be workable as long as the
original dependencies embedded in the packages
are good. (It would be a public archive, so
stats could shame the worst offenders.. ;)
Packages themselves are never patched. They remain
intact, unchanged and if possible read-only, directly
accessed only by the pkgfs and the pkgmanager.
Package updates trigger dep file updates.
Dep file updates do not trigger package updates.
They´re mostly advisory and meant for the package
manager which has to make sense of things and
communicate that to the user, so he/she can make
good choices.
However, an integrated way to search for and install
software is something that I would still hold on to
as a goal.
That would be nice.
The dep file online store I described could
double as a package database, like a next-gen
BeBits, or provide infrastructure for a simple
package manager like the one in Ubuntu.
(the "add/remove..." one)
