Hi, On Thu, Dec 09, 2004 at 22:25:02 -0500, Victor wrote:
Johannes Winkelmann wrote: [...]
Both are addressed in the aliases thing. I'm sorry I didn't include the discussion why we chose the aliases solution over complete virtual dependencies, but as you see, it's not only easier but also simpler and less prone to errors. If you'd like to create a port which is an alias to sendmail, and MTA would not be a virtual dependency yet, what you'd have to do is:
1. Ask someone(tm) to add the virtual dependency in the dependency list 2. Add a "provides: mta" field to sendmail 3. change every port depending on sendmail to depend on MTA 4. make sure every packager knows that he/she should use MTA now 5. Add "depends: mta" to your new Pkgfile [...] But can you then further explain the actual solution that would be included in the new pkgutils? I am not sure if the complexity you mention would be as difficult if port metadata is stored in the system, but I guess that would be off point. I was mostly referring to maintenance efforts, to maintain the list and communicate the changes, plus make sure they're used correctly. To be honest, there's a case which requires a lot more work in the alias solution compared to the pure virtual dependencies, that is when (if) sendmail gets replaced by postfix.
Sounds good. I am curious if there is a webpage or a todo list or any other docs on the new pkgutils develpment. If so, please post to the list. The basic idea is that the package database can store any kind of meta information, called 'attributes'... pkgmk and pkgadd would just pass it through. This would allow to include things like prt-get's locking flag to be added directly to the package db. Still, pkgmk and pkgadd wouldn't care. The idea we also had was that you could define additional filters what kind of information you'd like to include into your package database. This way, you could e.g. even include the descriptions into your database if you wanted to, allowing to get a description of a package without having a ports tree around.
Furthermore, the meta information would be included in the pkg.tar.gz, in a special place like e.g. /METADATA. Tools like pkg-get could then extract the information from the tar.gz, while pkgadd would just propagate it to the package database (those which are selected by a filter; e.g allow aliases and description). This way, package will still be backwards compatible and usable as plain tar.gz archives (okay, you'll end up with a /METADATA directory, but that's a minor issue). We haven't come up with a nice format to include those attributes into ports; one way is to have it in the package file, otherwise we could have an external 'attributes' file. Obviously, attributes can be added freely, which means that if someone can add attributes to ports he/she needs without having to change pkgutils. The possibilities are literally unlimited, but would cover most things we have in our CLC header right now (including aliases). I know it's still a pretty rough outline, but it should give you a better idea of the whole 'attribute' extension for pkgutils. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net