marcuscom and www/epiphany-extensions

[varga.michal at gmail.com]

On Thu, Feb 25, 2010 at 5:33 PM, Koop Mast <kwm at freebsd.org> wrote:
>> Technically I already did, actually it seems there are just minor
>> changes from 2.28. Though as a personal preference, I'd like to see
>> the prefix issue fixed first, but I'm not aware of any other port
>> currently that deals with this, so I'm not sure what's the correct
>> approach. Any ideas, or pointers?
>
> Seems hacking EPIPHANY_EXTENSIONS_DIR in configure is the only way to
> fix this. I'm not really bothered with this, since epiphany and the
> extension ports are installed in the same prefix. I'm not really
>
Well that's actually the issue - they aren't. What basically happens
(to be said, I'm really far from a ports guru) is that
epiphany-extensions partially uses other port's prefix, but without
making any record of it. Also, it's my understanding that installing
files outside defined prefix was always a big no-no. The problem is,
when using different prefixes for epiphany and different for
extensions (doesn't generally happen, but there is nothing to stop
user from doing that), some files will end up in different path
(namely, under epiphany's own prefix), but based on plist, package
deletion will try to remove these files from its installation prefix -
this will make epiphany-extensions pollute the system with files that
can't be removed thereafter (unless you know where they are and do
that manually, of course).


> But back to the matter at hand. Can you post the diff for the ports
> update, or do you want to try to fix the problem above first?
>
If it's not in hurry (I guess I'm the only user of epiphany-extensions
anyway, when nobody noticed that it's missing for months ;), I'd like
to fix it first. I'm just wondering what would be the best approach -
patching EPIPHANY_EXTENSIONS_DIR to honor PREFIX would work for proper
de/installation, but I assume - under different prefix then, epiphany
won't be able to find its extensions (which still is less evil than
leaving libraries behind. So basically, if you want them to work
together, install them into the same prefix). Would that be ok?

m.