| 1 |
Hi, |
| 2 |
|
| 3 |
Some of my points are probably already covered in your list, but let me |
| 4 |
show my wishlist: |
| 5 |
|
| 6 |
portage-ng should be ... |
| 7 |
|
| 8 |
- completely based on exchangable components (I don't like the term |
| 9 |
plugin here as plugins are IMO always optional) and each component |
| 10 |
should have a well defined interface as well as metadata stating |
| 11 |
dependencies on other components (e.g. a DB based tree backend needs a |
| 12 |
DB compatible sync mechanism and parser). |
| 13 |
|
| 14 |
- statically typed, so it can be better checked for errors before |
| 15 |
released. I realize that this might not be possible in several |
| 16 |
languages, but then at least we should enforce consistent typenames in |
| 17 |
the API documentation (as currently you often have to read the source to |
| 18 |
find out what parameter a function really wants). |
| 19 |
|
| 20 |
- able to be used as a secondary package manager, this would also |
| 21 |
include the ability to enable users to install packages in their |
| 22 |
homedirs using system packages for the dependencies. One important part |
| 23 |
of this is implementing pathspec. |
| 24 |
|
| 25 |
- as secure as possible. This includes signed packages (both source and |
| 26 |
binary) and automatic priorization of security related updates. |
| 27 |
|
| 28 |
That's all for now, but I think my first point implicates many other |
| 29 |
points mentioned by you. Let me elaborate a bit more by giving an |
| 30 |
example what components could be used in the current portage: |
| 31 |
- ebuild parser |
| 32 |
- metadata parser |
| 33 |
- profile parser |
| 34 |
- config parser |
| 35 |
- packagename/version parser |
| 36 |
- dependency resolver |
| 37 |
- rsync sync component |
| 38 |
- cvs sync component |
| 39 |
- http sync component (for snapshots) |
| 40 |
- filesystem portdir storage component |
| 41 |
- filesystem package database storage component |
| 42 |
- searching component |
| 43 |
... |
| 44 |
|
| 45 |
So now the portagesql guys for example could just write different |
| 46 |
portdir storage, sync and metadata parser components to use mysql as a |
| 47 |
backend for the metadata instead of re-implementing portage completely. |
| 48 |
For the dependency example above their storage component would need |
| 49 |
their sync component or, more flexible, it implements some write() |
| 50 |
functions that could be used by sync components implementing a suitable |
| 51 |
interface (but for instance a storage component for cd-rom based |
| 52 |
snapshots could not do that). I hope you get the idea. |
| 53 |
|
| 54 |
Marius |
| 55 |
|
| 56 |
-- |
| 57 |
Public Key at http://www.genone.de/info/gpg-key.pub |
| 58 |
|
| 59 |
In the beginning, there was nothing. And God said, 'Let there be |
| 60 |
Light.' And there was still nothing, but you could see a bit better. |
Archives