[gentoo-user] Modifying ebuilds, and dependency thoughts between hugin and luminance-hdr.

[gentoo-user] Modifying ebuilds, and dependency thoughts between hugin and luminance-hdr.

[Michael Mol]

So, media-gfx/luminance-hdr uses hugin's align_image_stack by default.
Except the ebuild doesn't list a dependency on hugin. I tried
modifying its ebuild file to add the dependency, but Portage
complained about a failed digest verification. So I don't know how to
work around that.

Then there are some additional realizations I had.

1) Pulling in hugin pulls in gtk and a bunch of additional
dependencies. Luminance-hdr is a qt app; having a qt app trigger
pulling in gtk seems silly.
2) The tool that luminance-hdr needs is a CLI tool. It doesn't need
the GUI side of hugin. So it should be possible to build that hugin
tool without the rest of its GUI. Sounds like another USE flag, or
perhaps splitting align_image_stack into a separate ebuild and having
both luminance-hdr and hugin pull that in.
3) Luminance-hdr doesn't *need* hugin; it has a builtin tool that
fills the same role, but behaves a bit differently. It should be
perfectly possible to remove hugin's tool from the list of options,
based on a USE flag.

Now, both hugin and luminance-hdr are both tools I've messed with a
great deal...enough to be frustrated with aspects which lead me to
dive into their source code to try to fix things. I'm pretty confident
I could do just about all of it, code-wise and logic-wise. What I
don't know is anything about ebuild and app development on Gentoo.*

So...where do I go from here?

* This also comes in on my desire to play The Old Republic, but WINE
1.3.x has trouble with it. Day job as a Win32 coder comes in handy
here...

-- 
:wq

Re: [gentoo-user] Modifying ebuilds, and dependency thoughts between hugin and luminance-hdr.

[Mark Knecht]

On Sat, Dec 24, 2011 at 12:23 PM, Michael Mol <mikemol@gmail.com> wrote:
> So, media-gfx/luminance-hdr uses hugin's align_image_stack by default.
> Except the ebuild doesn't list a dependency on hugin. I tried
> modifying its ebuild file to add the dependency, but Portage
> complained about a failed digest verification. So I don't know how to
> work around that.
>
> Then there are some additional realizations I had.
>
> 1) Pulling in hugin pulls in gtk and a bunch of additional
> dependencies. Luminance-hdr is a qt app; having a qt app trigger
> pulling in gtk seems silly.
> 2) The tool that luminance-hdr needs is a CLI tool. It doesn't need
> the GUI side of hugin. So it should be possible to build that hugin
> tool without the rest of its GUI. Sounds like another USE flag, or
> perhaps splitting align_image_stack into a separate ebuild and having
> both luminance-hdr and hugin pull that in.
> 3) Luminance-hdr doesn't *need* hugin; it has a builtin tool that
> fills the same role, but behaves a bit differently. It should be
> perfectly possible to remove hugin's tool from the list of options,
> based on a USE flag.
>
> Now, both hugin and luminance-hdr are both tools I've messed with a
> great deal...enough to be frustrated with aspects which lead me to
> dive into their source code to try to fix things. I'm pretty confident
> I could do just about all of it, code-wise and logic-wise. What I
> don't know is anything about ebuild and app development on Gentoo.*
>
> So...where do I go from here?
>
> * This also comes in on my desire to play The Old Republic, but WINE
> 1.3.x has trouble with it. Day job as a Win32 coder comes in handy
> here...
>
> --
> :wq
>

I haven't tried this in years but from this link:

http://www.gentoo.org/doc/en/handbook/2004.2/handbook-x86.xml?part=3&chap=6

there is this text:

[QUOTE]
If you are certain that the sources you've fetched and the ebuild
itself are valid, you can regenerate the Manifest and digest-<package>
file using ebuild's digest functionality:

Code Listing 2.3: Regenerate Manifest and digest

# ebuild path/to/ebuild digest
[QUOTE]

HTH,
Mark

Re: [gentoo-user] Modifying ebuilds, and dependency thoughts between hugin and luminance-hdr.

[Dale]

Mark Knecht wrote:
> On Sat, Dec 24, 2011 at 12:23 PM, Michael Mol<mikemol@gmail.com>  wrote:
>> So, media-gfx/luminance-hdr uses hugin's align_image_stack by default.
>> Except the ebuild doesn't list a dependency on hugin. I tried
>> modifying its ebuild file to add the dependency, but Portage
>> complained about a failed digest verification. So I don't know how to
>> work around that.
>>
>> Then there are some additional realizations I had.
>>
>> 1) Pulling in hugin pulls in gtk and a bunch of additional
>> dependencies. Luminance-hdr is a qt app; having a qt app trigger
>> pulling in gtk seems silly.
>> 2) The tool that luminance-hdr needs is a CLI tool. It doesn't need
>> the GUI side of hugin. So it should be possible to build that hugin
>> tool without the rest of its GUI. Sounds like another USE flag, or
>> perhaps splitting align_image_stack into a separate ebuild and having
>> both luminance-hdr and hugin pull that in.
>> 3) Luminance-hdr doesn't *need* hugin; it has a builtin tool that
>> fills the same role, but behaves a bit differently. It should be
>> perfectly possible to remove hugin's tool from the list of options,
>> based on a USE flag.
>>
>> Now, both hugin and luminance-hdr are both tools I've messed with a
>> great deal...enough to be frustrated with aspects which lead me to
>> dive into their source code to try to fix things. I'm pretty confident
>> I could do just about all of it, code-wise and logic-wise. What I
>> don't know is anything about ebuild and app development on Gentoo.*
>>
>> So...where do I go from here?
>>
>> * This also comes in on my desire to play The Old Republic, but WINE
>> 1.3.x has trouble with it. Day job as a Win32 coder comes in handy
>> here...
>>
>> --
>> :wq
>>
> I haven't tried this in years but from this link:
>
> http://www.gentoo.org/doc/en/handbook/2004.2/handbook-x86.xml?part=3&chap=6
>
> there is this text:
>
> [QUOTE]
> If you are certain that the sources you've fetched and the ebuild
> itself are valid, you can regenerate the Manifest and digest-<package>
> file using ebuild's digest functionality:
>
> Code Listing 2.3: Regenerate Manifest and digest
>
> # ebuild path/to/ebuild digest
> [QUOTE]
>
> HTH,
> Mark
>
>

And if I recall correctly, you have to do this again if you sync.  You 
may want to put that in a local overlay or something so that syncs don't 
change what you are fixing.  This is nothing I have done before but have 
read where others do it this way or at least the way I understood it 
anyway.

Hope that points you in some good direction.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-user] Modifying ebuilds, and dependency thoughts between hugin and luminance-hdr.

[Stroller]

On 24 December 2011, at 20:23, Michael Mol wrote:

> So, media-gfx/luminance-hdr uses hugin's align_image_stack by default.
> Except the ebuild doesn't list a dependency on hugin. I tried
> modifying its ebuild file to add the dependency, but Portage
> complained about a failed digest verification. So I don't know how to
> work around that.

# grep -i overlay /etc/make.conf 
PORTDIR_OVERLAY=/usr/local/portage
# mkdir -p /usr/local/portage/media-gfx/luminance-hdr/
# cp /usr/portage/media-gfx/luminance-hdr/luminance-hdr-2.1.0.ebuild /usr/local/portage/media-gfx/luminance-hdr/
# vi /usr/local/portage/media-gfx/luminance-hdr/luminance-hdr-2.1.0.ebuild
# ebuild /usr/local/portage/media-gfx/luminance-hdr/luminance-hdr-2.1.0.ebuild manifest


> 2) The tool that luminance-hdr needs is a CLI tool. It doesn't need
> the GUI side of hugin. So it should be possible to build that hugin
> tool without the rest of its GUI. Sounds like another USE flag, or
> perhaps splitting align_image_stack into a separate ebuild and having
> both luminance-hdr and hugin pull that in.

Sounds reasonable. Create a new ebuild for Hugin also, and add a USE=-X option.

> 3) Luminance-hdr doesn't *need* hugin; it has a builtin tool that
> fills the same role, but behaves a bit differently. It should be
> perfectly possible to remove hugin's tool from the list of options,
> based on a USE flag.

I'd have current behaviour depend on USE=hugin in that case. USE=-hugin by default.

Stroller.