| 1 |
On Wednesday 17 May 2006 01:15, Danny van Dyk wrote: |
| 2 |
> |
| 3 |
> There are several reasons to handle it slightly different: |
| 4 |
> a) Paludis is a new package manager, not a different kernel nor |
| 5 |
> userland. |
| 6 |
> b) We don't need additional packages that need to go into the tree and |
| 7 |
> which aren't used by any other arch than bsd. |
| 8 |
> c) We don't need to keyword any packages. |
| 9 |
> d) Paludis _can_ use existing profiles. There is no problem with that, |
| 10 |
> and we did this for quite some time already. Interesting part is the |
| 11 |
> multiple inheritance of profiles and the different (in my eyes |
| 12 |
> improved) handling of profile configuration. |
| 13 |
> |
| 14 |
> In my eyes, these warrant adding a toplevel profile directory. |
| 15 |
|
| 16 |
Your argumentation is unfortunately incomplete. Paludis is a package |
| 17 |
manager whose development and profiles can be tested largely outside the |
| 18 |
tree. While having a profile package for paludis might be inconvenient, |
| 19 |
the functionality is not different. |
| 20 |
|
| 21 |
The main point you fail to mention however is that paludis is as yet not |
| 22 |
complete. At some point in the stabilisation of paludis gentoo has to |
| 23 |
decide whether paludis will receive some level of official support. At |
| 24 |
that time tests involving in-tree profiles can be conducted. |
| 25 |
|
| 26 |
There are however a number of requirements I want to state that paludis |
| 27 |
should meet before I consider it a stable portage replacement: |
| 28 |
- Paludis must be able to handle a standard portage /var/db/pkg tree. This |
| 29 |
means that paludis can read it, and write it. Enabling mixing portage |
| 30 |
and paludis up to some degree. |
| 31 |
- Paludis must work with all current ebuilds, and support all features of |
| 32 |
portage. This includes recognition of EAPI, and no renaming of the |
| 33 |
variables used. |
| 34 |
- No part of the tree, except those that by nature are paludis specific, |
| 35 |
may require the usage of paludis instead of portage. This requirement |
| 36 |
can only be removed after a decision is made by the council to retire |
| 37 |
portage in favour of paludis. |
| 38 |
- It would be greatly beneficial if paludis would create and use .tbz2 |
| 39 |
packages, but this is not essential. |
| 40 |
|
| 41 |
Below I'll outline some of the consequences. |
| 42 |
|
| 43 |
- Paludis may enhance ebuilds by directing the build process into a more |
| 44 |
efficient behaviour. As long as the ebuild still functions properly on |
| 45 |
portage, this should not be an issue. Examples would be in-ebuild |
| 46 |
documentation of use variables, enhanced dependency handling. |
| 47 |
- Paludis enhanced packages (except paludis related ebuilds) should only |
| 48 |
be accepted into the tree when it is seen as a stable package manager. |
| 49 |
- Paludis may choose to handle different format package descriptions |
| 50 |
(.ebuild.2?). Those can not appear in the official tree though before |
| 51 |
paludis is recognised as primary package manager. |
| 52 |
- Overlays can be used for various ways to extend paludis. |
| 53 |
- The first requirement of reading /var/db/pkg can be interpreted twofold. |
| 54 |
Either paludis should support it natively (as one of the options), or it |
| 55 |
should be able to convert from and to the /var/db/pkg format. |
| 56 |
- It is allowed for out-of-tree package descriptions to require a |
| 57 |
different installed package database format. Things like paralel |
| 58 |
installation of 32bit and 64bit packages require this. As yet the tree |
| 59 |
should not offer this though. |
| 60 |
|
| 61 |
Paul |
| 62 |
|
| 63 |
-- |
| 64 |
Paul de Vrieze |
| 65 |
Gentoo Developer |
| 66 |
Mail: pauldv@g.o |
| 67 |
Homepage: http://www.devrieze.net |
Archives