[clc-devel] alias support in prt-get

Victor victord at v600.net
Fri Dec 10 03:25:02 UTC 2004


Johannes Winkelmann wrote:
> Hi Victor,
> 
<snip>
>>Alright, I guess when you start from end threads, you misunderstand the 
>>issue. :)
> 
> 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
>   place
> - 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 
solve here.

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
> course.

Ok.

>>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.

Victor



More information about the crux-devel mailing list