| 1 |
Mark Knecht wrote: |
| 2 |
> On Sat, Dec 24, 2011 at 12:23 PM, Michael Mol<mikemol@×××××.com> wrote: |
| 3 |
>> So, media-gfx/luminance-hdr uses hugin's align_image_stack by default. |
| 4 |
>> Except the ebuild doesn't list a dependency on hugin. I tried |
| 5 |
>> modifying its ebuild file to add the dependency, but Portage |
| 6 |
>> complained about a failed digest verification. So I don't know how to |
| 7 |
>> work around that. |
| 8 |
>> |
| 9 |
>> Then there are some additional realizations I had. |
| 10 |
>> |
| 11 |
>> 1) Pulling in hugin pulls in gtk and a bunch of additional |
| 12 |
>> dependencies. Luminance-hdr is a qt app; having a qt app trigger |
| 13 |
>> pulling in gtk seems silly. |
| 14 |
>> 2) The tool that luminance-hdr needs is a CLI tool. It doesn't need |
| 15 |
>> the GUI side of hugin. So it should be possible to build that hugin |
| 16 |
>> tool without the rest of its GUI. Sounds like another USE flag, or |
| 17 |
>> perhaps splitting align_image_stack into a separate ebuild and having |
| 18 |
>> both luminance-hdr and hugin pull that in. |
| 19 |
>> 3) Luminance-hdr doesn't *need* hugin; it has a builtin tool that |
| 20 |
>> fills the same role, but behaves a bit differently. It should be |
| 21 |
>> perfectly possible to remove hugin's tool from the list of options, |
| 22 |
>> based on a USE flag. |
| 23 |
>> |
| 24 |
>> Now, both hugin and luminance-hdr are both tools I've messed with a |
| 25 |
>> great deal...enough to be frustrated with aspects which lead me to |
| 26 |
>> dive into their source code to try to fix things. I'm pretty confident |
| 27 |
>> I could do just about all of it, code-wise and logic-wise. What I |
| 28 |
>> don't know is anything about ebuild and app development on Gentoo.* |
| 29 |
>> |
| 30 |
>> So...where do I go from here? |
| 31 |
>> |
| 32 |
>> * This also comes in on my desire to play The Old Republic, but WINE |
| 33 |
>> 1.3.x has trouble with it. Day job as a Win32 coder comes in handy |
| 34 |
>> here... |
| 35 |
>> |
| 36 |
>> -- |
| 37 |
>> :wq |
| 38 |
>> |
| 39 |
> I haven't tried this in years but from this link: |
| 40 |
> |
| 41 |
> http://www.gentoo.org/doc/en/handbook/2004.2/handbook-x86.xml?part=3&chap=6 |
| 42 |
> |
| 43 |
> there is this text: |
| 44 |
> |
| 45 |
> [QUOTE] |
| 46 |
> If you are certain that the sources you've fetched and the ebuild |
| 47 |
> itself are valid, you can regenerate the Manifest and digest-<package> |
| 48 |
> file using ebuild's digest functionality: |
| 49 |
> |
| 50 |
> Code Listing 2.3: Regenerate Manifest and digest |
| 51 |
> |
| 52 |
> # ebuild path/to/ebuild digest |
| 53 |
> [QUOTE] |
| 54 |
> |
| 55 |
> HTH, |
| 56 |
> Mark |
| 57 |
> |
| 58 |
> |
| 59 |
|
| 60 |
And if I recall correctly, you have to do this again if you sync. You |
| 61 |
may want to put that in a local overlay or something so that syncs don't |
| 62 |
change what you are fixing. This is nothing I have done before but have |
| 63 |
read where others do it this way or at least the way I understood it |
| 64 |
anyway. |
| 65 |
|
| 66 |
Hope that points you in some good direction. |
| 67 |
|
| 68 |
Dale |
| 69 |
|
| 70 |
:-) :-) |
| 71 |
|
| 72 |
-- |
| 73 |
I am only responsible for what I said ... Not for what you understood or how you interpreted my words! |
| 74 |
|
| 75 |
Miss the compile output? Hint: |
| 76 |
EMERGE_DEFAULT_OPTS="--quiet-build=n" |
Archives