<br><font size=2 face="sans-serif">Hi,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the reactions.</font>
<br>
<br><font size=2 face="sans-serif">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;</font>
<br><font size=2 face="sans-serif">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:</font>
<br><font size=2 face="sans-serif">A dependency could then be a virtual-feature
without version, where WPKG would default to the latest available (stable)
version</font>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">Best Regards</font>
<br>
<br><font size=2 face="sans-serif">Robin</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">From:</font>
<td><font size=1 face="sans-serif">Rainer Meier <r.meier@wpkg.org></font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">To:</font>
<td><font size=1 face="sans-serif">Robin Roevens <robin.roevens@cocks.be></font>
<tr>
<td valign=top><font size=1 color=#5f5f5f face="sans-serif">Cc:</font>
<td><font size=1 face="sans-serif">wpkg-users@lists.wpkg.org</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Date:</font>
<td><font size=1 face="sans-serif">09.10.2008 18:22</font>
<tr valign=top>
<td><font size=1 color=#5f5f5f face="sans-serif">Subject:</font>
<td><font size=1 face="sans-serif">Re: [wpkg-users] Regex in depend tag?
Or other method?</font></table>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>Hi,<br>
<br>
Robin Roevens wrote:<br>
> I'm fairly new to WPKG and considering to use it so at the moment
I'm<br>
> designing the packages and profiles that I'm hoping to use...<br>
> But I stumbled on a practical problem: Some computers have/need firefox<br>
> 1.5 and some have/need firefox 3.x .. So I have 2 packages: firefox15<br>
> and firefox3<br>
> But then I also have AdobeFlash-firefoxplugin as a package, which<br>
> depends on firefox.. Can you already see my problem here?<br>
<br>
Yes, if you need two different sets of software on different machines,<br>
then you need to create a profile for each of them. You might either<br>
completely duplicate it or create a profile with a common subset and<br>
then create two concrete profiles depending on the common one (actually<br>
inheriting its content) and adding the firefox package (one adds FF 1.5,<br>
one adds FF 3.x).<br>
<br>
Then assign the correct profiles to each host.<br>
<br>
<br>
> Is there a way for this package to depend on firefox15 OR firefox3<br>
> whatever is installed without having to create 2 seperate packages
with<br>
> the dependancy as the only difference.<br>
> I was thinking about using a regex "firefox.+", but since
it is nowhere<br>
> documented, I assume it is not implemented in wpkg either and regexes<br>
> only work on hosts?<br>
<br>
No, regex is not supported for package references. This has a simple<br>
reason. If you include or depend on a package you cannot specify a regex<br>
as it could match multiple package (which is exactly the intention). If<br>
it matches multiple packages, then WPKG does not know which one actually<br>
to install.<br>
<br>
Well, there might be a solution for it. Each package could provide a set<br>
or "virtual" features where both Firefox packages could provide
a<br>
feature like "webbrowser" and you have a package depending on<br>
"webbrowser". The drawback of this solution is the same as outlined<br>
above. If no package providing "webbrowser" is installed WPKG
does not<br>
know which one to install.<br>
Instead currently you can specify a direct dependency on another<br>
package. If this package is not installed WPKG will take care about and<br>
install it.<br>
In your case you would need two Flash-Plugin packages, one depending on<br>
FF 1.5 and one on FF 3.x, then just add the correct one to the profile<br>
you create.<br>
<br>
e.g.<br>
profile: common<br>
- package a<br>
- package b<br>
- package c<br>
...<br>
<br>
profile: users1<br>
- depends on profile "common"<br>
- package FF 1.5<br>
- package FF-1-flash<br>
<br>
profile: users2<br>
- depends on profile "common"<br>
- package FF 3.x<br>
- package FF-3-flash<br>
<br>
<br>
> Or is there some other decent method to handle this problem?<br>
<br>
As written above. Use different profiles for different applications<br>
installed.<br>
<br>
> Even greater would probably be that there is a bit more version-control.<br>
> So packages with a same name can exist as long as the revision differs.<br>
> Then there could be dependencies to packages of at least revision
x or<br>
> with a revision lower than y and such.. and maybe even a stable and
a<br>
> testing/unstable branch, or is that going over the top? :-)<br>
<br>
There is an idea to allow including of specific versions to a profile.
I<br>
will think about the possibility to create a dependency on a specific<br>
version as well. However even if supported I would not recommend it. The<br>
reason is simple - having a large package tree makes it difficult to<br>
maintain the packages as you always have to upgrade some dependencies<br>
and profiles which might still include the old version (leading to<br>
invalid dependencies/profiles).<br>
<br>
<br>
br,<br>
Rainer<br>
</font></tt>
<br>
<br>