[clc-devel] alias support in prt-get
victord at v600.net
Thu Dec 9 05:24:14 UTC 2004
Johannes Winkelmann wrote:
> I've just uploaded a test version of prt-get (0.5.9-test2) to my
> personal httpup repo  which has support for "aliases", a concept we
> discussed at CRUXCon; the idea is that a package can have a number of
> aliases, which can be used to do dependency resolving. The most typical
> example is probably sendmail and its replacements; in this case, we'd
> alias all the other MTA's as being sendmail. It's sortof what other
> package management systems have with "virtual dependencies" or
> "provides", just adapted. The idea is not to look for generic terms for
> something and alias all others (think: 'windowmanager', 'browser' etc.)
> but for dependencies which can be provided by others.
> A second example is Java, where the Software Development Kit (SDK)
> provides a Java Runtime Environment (JRE) too.
> In the future, this infomation should live in the ports itself and be
> transferred to the package database, but until this is ready, prt-get
> reads /var/lib/pkg/aliases and gets its information there from. This
> file is currently really sparse, which is the main reason for this
> e-mail: I'd like to hear suggestions for possible aliases to include;
> please send it to the list so we can have a little discussion if needed.
> What's currently there is the following:
> postfix: sendmail
> j2sdk: j2re
Alright, I guess when you start from end threads, you misunderstand the
I don't see why it's easier to do this, instead of doing
mta: postfix sendmail exim
java: j2sdk j2re
Otherwise, it seems to me, there is a lot of duplication where every
port has to note every other port.
For easier grep, maybe:
is the easiest approach. The problem with listing OTHER ports is
prerequisite knowledge. While I understand it's easier to list ports for
easy grepping, I am not sure the tradeoff there is a good one, as it
shifts too much of the burden onto the packager to actually know ALL
conflicting ports (and having to update these ports when new "mta" ports
One rules of OO design is that you should never have to go back to
modify existing code to extend it. 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.
But that's just my opinion, I could be wrong.
More information about the crux-devel