[clc-devel] alias support in prt-get
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> This is also the first step to resolve the issues we have with Java right now; stay tuned for more :-). A few examples from prt-get: $ prt-get depends firefox-java-plugin -- dependencies ([i] = installed) [i] j2re (provided by j2sdk) [...] [i] firefox [i] firefox-java-plugin $ prt-get isinst j2re j2re is provided by package j2sdk $ A possible downside is that there's no way to force prt-get to install j2re if you have j2sdk installed. IMO this is even better this way, but it might not always be wanted; I'm thinking about a --noalias switch to disable alias considerations completely, but I want to give that some thought (and probably wait until someone really wants this). So, as mentioned before, I'd like to hear additions to my "aliases" list. Kind regards, Johannes References: 1. http://jw.tks6.net/files/crux/ports#prt-get -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On Mon, Dec 06, 2004 at 11:38:16PM +0100, Johannes Winkelmann wrote:
Hi,
Hi Johannes,
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;
thanks :-) [...]
So, as mentioned before, I'd like to hear additions to my "aliases" list.
exim: sendmail masqmail: sendmail Greetings Jürgen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
--- Juergen Daubert <jue@jue.li> wrote:
So, as mentioned before, I'd like to hear additions to my "aliases" list.
blowupdoll: girlfriend You can find the port for blowupdoll in my httpup repository. ===== Jay Dolan Software Engineer, Systems Analyst Windmill Cycles, Inc. 508.999.4000 __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250
Juergen Daubert wrote:
On Mon, Dec 06, 2004 at 11:38:16PM +0100, Johannes Winkelmann wrote:
Hi,
Hi Johannes,
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;
thanks :-)
[...]
So, as mentioned before, I'd like to hear additions to my "aliases" list.
exim: sendmail masqmail: sendmail
Not to be picky, but sendmail is NOT the right alias. mta or mailsystem or postmaster, but NOT sendmail. Victor
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
Hi Victor, On Thu, Dec 09, 2004 at 00:24:14 -0500, Victor wrote: > Johannes Winkelmann wrote: [...] > >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. :) Hard to say, considering that we've spent quite some time discussion this at CRUXCon... > 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. 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 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. > 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. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
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
Hi Victor, On Thu, Dec 09, 2004 at 22:25:02 -0500, Victor wrote:
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 :) Okay, I guess I missunderstood that, sorry!
[...]
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. I prepared a summary of CRUXCon, I hope I'll find the time to put up a wiki page today or tomorrow!
Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Hi, On Thu, Dec 09, 2004 at 22:25:02 -0500, Victor wrote:
Johannes Winkelmann wrote: [...]
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 [...] 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. I was mostly referring to maintenance efforts, to maintain the list and communicate the changes, plus make sure they're used correctly. To be honest, there's a case which requires a lot more work in the alias solution compared to the pure virtual dependencies, that is when (if) sendmail gets replaced by postfix.
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. The basic idea is that the package database can store any kind of meta information, called 'attributes'... pkgmk and pkgadd would just pass it through. This would allow to include things like prt-get's locking flag to be added directly to the package db. Still, pkgmk and pkgadd wouldn't care. The idea we also had was that you could define additional filters what kind of information you'd like to include into your package database. This way, you could e.g. even include the descriptions into your database if you wanted to, allowing to get a description of a package without having a ports tree around.
Furthermore, the meta information would be included in the pkg.tar.gz, in a special place like e.g. /METADATA. Tools like pkg-get could then extract the information from the tar.gz, while pkgadd would just propagate it to the package database (those which are selected by a filter; e.g allow aliases and description). This way, package will still be backwards compatible and usable as plain tar.gz archives (okay, you'll end up with a /METADATA directory, but that's a minor issue). We haven't come up with a nice format to include those attributes into ports; one way is to have it in the package file, otherwise we could have an external 'attributes' file. Obviously, attributes can be added freely, which means that if someone can add attributes to ports he/she needs without having to change pkgutils. The possibilities are literally unlimited, but would cover most things we have in our CLC header right now (including aliases). I know it's still a pretty rough outline, but it should give you a better idea of the whole 'attribute' extension for pkgutils. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
participants (5)
-
Jay Dolan -
Johannes Winkelmann -
Juergen Daubert -
Nick Steeves -
Victor