[pulseaudio-discuss] [PATCH] Add a .travis.yml for Travis CI

[Arun Raghavan]

On 16 April 2015 at 18:47, Felipe Sateler <fsateler at gmail.com> wrote:
> On 16 April 2015 at 06:23, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote:
>> On Thu, 2015-04-16 at 14:25 +0530, Arun Raghavan wrote:
>>> On 16 April 2015 at 14:23, Tanu Kaskinen <tanu.kaskinen at linux.intel.com> wrote:
>>> > On Wed, 2015-04-15 at 12:43 -0300, Felipe Sateler wrote:
>>> >> But some reasons for installing packages explicitly:
>>> >>
>>> >> 1. Not in build-dep (git-core, check)
>>> >> 2. Version upgrade after adding the trusty repositories. The build
>>> >> failed if I didn't upgrade the autotools before building (not sure
>>> >> why).
>>> >
>>> > So "apt-get build-dep" doesn't automatically upgrade all dependencies if
>>> > they're already installed? And you didn't want to do a full system
>>> > upgrade from 12.04 to 14.04.
>>> >
>>> >> 3. Me being lazy. dh-autoreconf is not used but I know it brings in
>>> >> all the required deps for running autotools (we use that in the debian
>>> >> package).
>>> >>
>>> >> Some pruning may be possible, but perhaps it is better to scrap the
>>> >> build-dep and be explicit on what is depended upon.
>>> >
>>> > Having an explicit list of the build dependencies seems like the best
>>> > way forward.
>>>
>>> I'm not a huge fan of this since we'd have to remember to update the
>>> file each time deps change. Using the Ubuntu packaging deps seems more
>>> pragmatic.
>>
>> Well, "apt-get build-dep" is great in theory, but it sounds like it may
>> result in some dependencies coming from 12.04 and some from 14.04,
>> because already-installed packages don't get updated, and according to
>> Felipe, that already caused problems with autotools. What do you think
>> would be the best way to solve this?
>
> I'd favor putting the whole list in the travis file. Advantages of doing so:
>
> 1. Tested documentation on required build dependencies.
> 2. Installing manually instead of build-dep makes apt upgrade the
> dependencies in question. Given that the base environment is 3 years
> old, we should be doing this anyway. Unfortunately, a dist-upgrade is
> not the best option for this since the environment is not quite
> pristine (I tried this and it failed).
> 3. No need to worry to keep in sync between what is in the ubuntu
> package vs upstream. Ubuntu might have some options disabled due to
> core/non-core distinctions (I believe that is why libweb-rtc is not
> enabled in ubuntu) or simply because the ubuntu release is too old.
>
> Also, we can just pick up the base from the ubuntu package so it is
> not much extra work either.

Okay, I'm game to go with this approach and see how it goes.

-- Arun