From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Jan Hoogenraad <jan-verisign@hoogenraad.net>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: change in build .sh due to Pulseaudio device removal /
Date: Sun, 19 Jun 2011 09:15:05 -0300 [thread overview]
Message-ID: <4DFDE849.8030404@redhat.com> (raw)
In-Reply-To: <4DFCDE6D.8090008@hoogenraad.net>
Em 18-06-2011 14:20, Jan Hoogenraad escreveu:
> Mauro:
>
> The change in build.sh
> http://git.linuxtv.org/media_build.git?a=commitdiff;h=16cf0606fd59484236356e400a89c083e76da64b
>
> now requires installation of a Perl package Proc::ProcessTable that is not present in standard Ubuntu systems.
>
> I needed to run
> sudo aptitude install libproc-processtable-perl
> before I could continue after the change.
>
> Is there a way around this ?
The media_build requires several packages that may not be present on some
installation. The build.sh script has a logic to detect the missing parts
and to output what's the missing requirements:
echo "Checking if the needed tools are present"
run ./check_needs.pl
(I moved right now the perl-specific checks into check_needs.pl script)
Unfortunately, package names are distro-specific. So, as I use only Fedora/RHEL
here, the only hints it have are for them. From my experiences, between the
rpm-based distros, the package names are either equal or very close, so such
hints probably are probably good enough for Suse and Mandriva users.
>From what I understand, the standard Ubuntu repositories already provide a package
for Proc::ProcessTable. So, the only thing that it is not ok is the package name hint.
Could you please provide us a patch adding the Ubuntu (and likely Debian) package
name?
IMHO, the better would be to modify the check logic, in order to check what's the
system, and provide a hint based on it. If the OS type is not found, then fall back
to some default.
I think that the LSB default to get the distribution is by reading /etc/system-release.
Those are provided on RHEL6 and Fedora (plus, the old way: /etc/redhat-release).
So, IMHO, all we need to do is to write a logic for the error report part of the check,
that opens /etc/system-release, identify what's the distro, and provide the package
name and some instructions on how to install the missing parts to the userspace.
The right way for adding such logic would be to install the OS's on some VM with the
minimum install, run the script and add the missing parts on it.
Cheers,
Mauro.
next prev parent reply other threads:[~2011-06-19 12:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-17 20:08 Pulseaudio device removal Mauro Carvalho Chehab
2011-06-18 17:20 ` change in build .sh due to Pulseaudio device removal / Jan Hoogenraad
2011-06-19 12:15 ` Mauro Carvalho Chehab [this message]
2011-06-19 12:40 ` Jan Hoogenraad
2011-06-19 12:50 ` Mauro Carvalho Chehab
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=4DFDE849.8030404@redhat.com \
--to=mchehab@redhat.com \
--cc=jan-verisign@hoogenraad.net \
--cc=linux-media@vger.kernel.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