| 1 |
Daniel Robbins <drobbins@g.o> writes: |
| 2 |
|
| 3 |
> On Mon, Jul 09, 2001 at 04:40:02PM +0200, Terje Kvernes wrote: |
| 4 |
> |
| 5 |
> > what you're basically saying is that it's up to the person making |
| 6 |
> > each build to make the choice of which lib to prioritize. |
| 7 |
> > personally, I find this rather icky, because it demands that the |
| 8 |
> > person installing the packages can't say "media(gdkpixbuf,imlib) |
| 9 |
> > and be sure that nothing ever needing just gdkpixbuf won't install |
| 10 |
> > imlib. |
| 11 |
> |
| 12 |
> The problem is that as of right now, our USE variables don't express |
| 13 |
> preference, just whether a particular extension is acceptable or |
| 14 |
> not. |
| 15 |
|
| 16 |
right, that's the problem. the question is how bad a problem it is. |
| 17 |
I have _no_ big issues with it currently, I'm just wondering if it's |
| 18 |
something that should be addressed. |
| 19 |
|
| 20 |
> There may be applications that can link to *both* gdkpixbuf and |
| 21 |
> imlib. There are really two easy solutions; and ebuild can prefer |
| 22 |
> the more advanced replacement if defined, or if there is an |
| 23 |
> either/or choice (if it's not possible to add support for both), we |
| 24 |
> can create two ebuilds: |
| 25 |
> |
| 26 |
> foo-gdkpixbuf |
| 27 |
> foo-imlib |
| 28 |
|
| 29 |
which means someone[tm] will have to maintain two different builds |
| 30 |
of what is practically the same package. it's not a very clean |
| 31 |
solution. |
| 32 |
|
| 33 |
> The either/or option doesn't seem to happen *too* often, so this |
| 34 |
> solution could work too. |
| 35 |
|
| 36 |
yeah, and as long as people keep their things up to date, sure. |
| 37 |
honestly, I'm not really worried, but it might become a case when |
| 38 |
foo has a security-issue, and the person packing it only uses |
| 39 |
foo-bar, and doesn't see foo-baz because it's not his domain. |
| 40 |
|
| 41 |
(call me paranoid, but I've had this crash on me with rpm, where the |
| 42 |
new package suddenly didn't cover all the same files because it came |
| 43 |
from another packager) |
| 44 |
|
| 45 |
> The harder third option is to increase the expressiveness of our USE |
| 46 |
> syntax, which *is* an option but I'd like to try the above solutions |
| 47 |
> first. |
| 48 |
|
| 49 |
okies. :-) |
| 50 |
|
| 51 |
> The advantage to our current approach to USE is that it's quite |
| 52 |
> straightforward. If something is in USE, the ebuild will build-in |
| 53 |
> that functionality if it can. That's easy for new users to |
| 54 |
> understand. |
| 55 |
|
| 56 |
true. then again, I really don't see how making USE express |
| 57 |
preference will manage to bite anyone. it does pretty much what |
| 58 |
you'd expect, it USEs the needed (and possible to use) packages in |
| 59 |
the given order. if both can be used, both are used. the current |
| 60 |
action isn't any more apparent, since you don't _know_ which of the |
| 61 |
packages will be used. you'll have to read the ebuild-file. |
| 62 |
|
| 63 |
I'm not familiar enough with freeBSD to know how they solve these |
| 64 |
cases. I looked a bit over the ports-documentation from the net, but |
| 65 |
didn't find anything. I'm guessing it's not a big case in reality. |
| 66 |
|
| 67 |
-- |
| 68 |
Terje |
Archives