[clc-devel] alias support in prt-get

Victor victord at v600.net
Thu Dec 9 05:24:14 UTC 2004


Johannes Winkelmann wrote:
> Hi,
> 
> I've just uploaded a test version of prt-get (0.5.9-test2) to my
> personal httpup repo [1] 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:
> 
> <quote>
> postfix: sendmail
> j2sdk: j2re
> </quote>

Alright, I guess when you start from end threads, you misunderstand the 
issue. :)

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:

    postfix: mta
    sendmail: mta
    eximi: mta

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 
are added).

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.

Victor



More information about the crux-devel mailing list