[clc-devel] alias support in prt-get
jw at tks6.net
Fri Dec 10 13:59:40 UTC 2004
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 at tks6.net
Bern, Switzerland http://jw.tks6.net
More information about the crux-devel