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