[clc-devel] alias support in prt-get
victord at v600.net
Fri Dec 10 03:25:02 UTC 2004
Johannes Winkelmann wrote:
> Hi Victor,
>>Alright, I guess when you start from end threads, you misunderstand the
> Hard to say, considering that we've spent quite some time discussion
> this at CRUXCon...
No, I meant me, first responding to an end thread :)
> There are two disadvantages:
> - you have to define those virtual dependencies, probably in a central
> - which one's the default? The first one?
> 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
I see what you're saying, you are talking implementation-wise, where
"mta" would be a fake virtual port that other ports can be an alias for.
However, that wasn't quite the way I thought of it. This seems ok to
me, not too shabby. In a way, it seems you just substituted "mta" with
"sendmail" and since sendmail is an existing port, that works for things
that "require" sendmail. I understand the issue you're attempting to
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.
> For our alias solution, it about that:
> 1. Add "alias: sendmail" to your new Pkgfile
> Even if the virtual dependencies might seem a bit cleaner, the
> complexity they bring along a lot bigger than any advantage. IMHO, of
>>In the listed approach, any time a new port that is an mta is added,
>>existing ports must be modified, which is not a good approach in my
>>opinion. Having "generalized" keys is easier and "better". However,
>>now the port system would have to store that metadata somewhere.
>>Perhaps a good approach for storing port metadata is what we really
>>need, instead of workarounds that don't address the problem properly.
> Yes, there will be one, but this will be the next generation pkgutils.
> Given that it's a major change there, this won't be ready for the next
> release of CRUX. prt-get's aliases workaround will go away then, but
> since that the problem exists now, and that it mostly affects prt-get's
> dependency command, it's also addressed there.
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.
More information about the crux-devel