public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
From: Mark Knecht <markknecht@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Modifying ebuilds, and dependency thoughts between hugin and luminance-hdr.
Date: Sat, 24 Dec 2011 12:34:59 -0800	[thread overview]
Message-ID: <CAK2H+eed8KXvEY3tNJrL845Ju1d4N2bcgee2EYN5q1fS8vjPeA@mail.gmail.com> (raw)
In-Reply-To: <CA+czFiBg2Z9FJs4T7=ve762wo4JJnNEpdCYO2L1tsFz-qpmqEw@mail.gmail.com>

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



  reply	other threads:[~2011-12-24 20:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-24 20:23 [gentoo-user] Modifying ebuilds, and dependency thoughts between hugin and luminance-hdr Michael Mol
2011-12-24 20:34 ` Mark Knecht [this message]
2011-12-24 21:25   ` Dale
2011-12-25  3:26 ` Stroller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK2H+eed8KXvEY3tNJrL845Ju1d4N2bcgee2EYN5q1fS8vjPeA@mail.gmail.com \
    --to=markknecht@gmail.com \
    --cc=gentoo-user@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox