[haiku-depot-web] Re: Progress
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-depot-web@xxxxxxxxxxxxx
- Date: Tue, 08 Oct 2013 18:12:14 +0200
On 10/08/2013 11:11 AM, Andrew Lindesay wrote:
I'm making quite good headway so far; I have the HPKR file reader
basically done and also a factory for transferring the HPKR data into
package-oriented DTO objects. I've got some really basic unit tests in
place for the HPKR reader and for the DTO factory. I've also done
simple tools for dumping the attributes and dumping a basic line about
each package to the stdout. Next thing is to scaffold a basic server
module...
Very nice progress!
Ingo; thanks for the great documentation.
Also thanks to Oliver. Though we could have done better; e.g. there
isn't any documentation of the package kit yet. I think documentation is
an aspect that is often neglected, although it can be so helpful to
lower the entrance barrier for people and preserve knowledge that cannot
be easily gotten from the code.
Apropos documentation, I had a closer look at the data model ER diagram
and noticed a few things:
* "Vendor" already has a meaning in the PM context. It is, for want of a
better description, the owner of a repository. Each package in a
repository is tagged with the same vendor string. It is used by the
dependency solver as a criterion to achieve a better cohesiveness of the
installed packages.
For a package foo that has a requirement lib:libbar it is generally
preferable to satisfy that requirement with a package from the same
vendor. Unless explicitly requested otherwise by the user.
TBH, I don't know in which situations and how strongly the solver
enforces the criterion.
Anyway, long story short, it looks like the Vendor entity in the diagram
means something else. At least there's no relationship with Repository,
but one with User.
* While a package is the only granularity of software solver and package
manager deal with ATM, often multiple packages are built from a single
software -- in HaikuPorts lingo: a port. E.g. the build recipe for a
port for a library can produce a package with library itself (only what
is needed for running programs linked against it), a devel package
(including the headers and other development files), a debuginfo package
(debug information for the debugger), maybe a separate doc package,
maybe separate packages for bindings for scripting languages.
In HaikuDepot and/or the web app it may be useful to group packages by
port again. ATM there is no reliable way to deduce which port a package
belongs to from its name, though. As it is implemented now -- but this
may change -- a build recipe always produces one (main) package named
like the port and optionally other packages named "<portName>_<suffix>".
Some of the suffixes ("devel", "debuginfo", "doc", "source") are
quasi-standardized, but there are port specific ones as well (e.g.
gettext_libintl). And there are ports like "apr" and "apr_util" which
make guessing the port name from a package name ambiguous.
So, if the grouping is found desirable, we may want to introduce a
package attribute to identify the port, and the web app design should
already take this into account. Until the attribute is available, the
port relationship could be guessed (if not always correctly, though).
CU, Ingo
Other related posts:
