Hi, Thanks for the reactions. I now understand the problem that can arise when regexes would be allowed in the depend tag. But combining both idea's you suggested, I think would be a great feature; If packages provide a virtual-feature and a version then i think it wouldn't be any problem to have packages depend on virtual-features and versions: A dependency could then be a virtual-feature without version, where WPKG would default to the latest available (stable) version Or it could be a virtual-feature of a specific version, where WPKG would not have a choice, and has to install that specific version of dependency. Or it could be a greater-than or lesser-than version dependency, where WPKG selects the highest available version of the dependency greater-than or lesser-than the specified version. Granted, it will make managing the packages a little more difficult when these features are used (but the current method can then be easily simulated when such version-dependencies are not needed). But when such features are actually needed for a number of packages, I think it is more difficult to keep managing the packages/profiles when work-arounds are needed like creating different profiles, depending on each other and duplicate packages with only a different name and dependency or even creating external scripts/batch-files to check if all dependencies are met, as suggested by Tomasz. Managing/maintaining the packages with virtual/version and extended dependency support could then be made a little easier again with maybe an extra tool/script which generates/displays a dependency graph, so misconfigurations in this can be easily tracked. Such features are already provided by most of the Linux package managers (ex. Gentoo's Portage/ebuild system), which are very very big package repositories with a lot of inter-dependencies but still seem not too hard to be managed, so I think it should be possible to have something alike in WPKG. Best Regards Robin From: Rainer Meier <r.meier at wpkg.org> To: Robin Roevens <robin.roevens at cocks.be> Cc: wpkg-users at lists.wpkg.org Date: 09.10.2008 18:22 Subject: Re: [wpkg-users] Regex in depend tag? Or other method? Hi, Robin Roevens wrote: > I'm fairly new to WPKG and considering to use it so at the moment I'm > designing the packages and profiles that I'm hoping to use... > But I stumbled on a practical problem: Some computers have/need firefox > 1.5 and some have/need firefox 3.x .. So I have 2 packages: firefox15 > and firefox3 > But then I also have AdobeFlash-firefoxplugin as a package, which > depends on firefox.. Can you already see my problem here? Yes, if you need two different sets of software on different machines, then you need to create a profile for each of them. You might either completely duplicate it or create a profile with a common subset and then create two concrete profiles depending on the common one (actually inheriting its content) and adding the firefox package (one adds FF 1.5, one adds FF 3.x). Then assign the correct profiles to each host. > Is there a way for this package to depend on firefox15 OR firefox3 > whatever is installed without having to create 2 seperate packages with > the dependancy as the only difference. > I was thinking about using a regex "firefox.+", but since it is nowhere > documented, I assume it is not implemented in wpkg either and regexes > only work on hosts? No, regex is not supported for package references. This has a simple reason. If you include or depend on a package you cannot specify a regex as it could match multiple package (which is exactly the intention). If it matches multiple packages, then WPKG does not know which one actually to install. Well, there might be a solution for it. Each package could provide a set or "virtual" features where both Firefox packages could provide a feature like "webbrowser" and you have a package depending on "webbrowser". The drawback of this solution is the same as outlined above. If no package providing "webbrowser" is installed WPKG does not know which one to install. Instead currently you can specify a direct dependency on another package. If this package is not installed WPKG will take care about and install it. In your case you would need two Flash-Plugin packages, one depending on FF 1.5 and one on FF 3.x, then just add the correct one to the profile you create. e.g. profile: common - package a - package b - package c ... profile: users1 - depends on profile "common" - package FF 1.5 - package FF-1-flash profile: users2 - depends on profile "common" - package FF 3.x - package FF-3-flash > Or is there some other decent method to handle this problem? As written above. Use different profiles for different applications installed. > Even greater would probably be that there is a bit more version-control. > So packages with a same name can exist as long as the revision differs. > Then there could be dependencies to packages of at least revision x or > with a revision lower than y and such.. and maybe even a stable and a > testing/unstable branch, or is that going over the top? :-) There is an idea to allow including of specific versions to a profile. I will think about the possibility to create a dependency on a specific version as well. However even if supported I would not recommend it. The reason is simple - having a large package tree makes it difficult to maintain the packages as you always have to upgrade some dependencies and profiles which might still include the old version (leading to invalid dependencies/profiles). br, Rainer -- ** Email Disclaimer: ** This e-mail and the information it contains may be confidential, legally privileged and protected by law. Access by the intended recipient only is authorised. If you are not the intended recipient, please notify the sender immediately and delete this e-mail from your system. Any review, distribution, reproduction, publication or other use of this e-mail by persons or entities other than the intended recipient is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20081010/d0ece03d/attachment.html> |