[Bug 518546] Review Request: libva - VAAPI video playback acceleration

bugzilla at redhat.com bugzilla at redhat.com
Wed Nov 24 04:37:46 UTC 2010


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=518546

--- Comment #58 from Jason Tibbitts <tibbs at math.uh.edu> 2010-11-23 23:37:44 EST ---
(In reply to comment #56)
> I thought that was already done in our default optflags?

'tis not, I'm afraid.  Not that it's a big deal anyway.

> This isn't really Fedora policy, most things aren't multilib in Fedora and we
> don't apparently split libs from binaries as a matter of course. Only things
> you might actually want to install the 32-bit version of on a 64-bit system are
> explicitly marked multilib.

Perhaps the process has changed; it used to involve a magic formula and the
presence of a -devel package.  Looking at the mash code, though, I'm pretty
sure this will end up multilibbed.  Unless I'm misunderstanding the mash code,
of course.

> I can't see any reason you'd want to do that with libva.

It's not something that someone explicitly does.  And even if I'm wrong and it
turns out not to be multilibbed, it may later become multilibbed if some
multilib package enters the distro which depends on it.

So, yeah, pretty sure it's going to be multilib and you'll have a conflict with
the file in /usr/bin.  But if you want, sure, wait to see what the first mash
does.

> What do you think is missing? The comments list the entire sequence.

I guess what's throwing me is the fact that usually this kind of modified
tarball thing involves simply deleting the bad content, so a recursive diff
would just list a few deleted files instead of giving a few thousand lines of
modifications.  Fixing up things to build and running autotools and such would
normally be done within the spec itself.  To see such a huge diff starts to
look more like an internal fork than a simple deletion of a few files.

> yeah, I know, I guess I'll do that. Though someone might want to pull it into
> EPEL, I guess, and they're not doing much harm.

Oh, there's no requirement to remove that stuff.  I just remind people that it
can be done.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the package-review mailing list