trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: January 2014

Re: [trinity-devel] hal & 3.5.13-sru - future -> argument to bring hal in-house

From: "David C. Rankin" <drankinatty@...>
Date: Thu, 16 Jan 2014 19:34:00 -0600
On 01/16/2014 05:44 PM, Darrell Anderson wrote:
> Me personally? No. :)
> 
> How many Trinity users are still using HAL based distros? Does 
> Trinity build on those older releases?
> 
> The oldest Slackware release upon which I can build Trinity is 
> 13.1, which is HAL based. Trinity won't build on older releases for 
> other reasons but HAL is not one of those reasons.
> 

3.5.13 will build on anything, R14??

> Rather than supporting a full blown HAL git branch, how about just 
> uploading upstream patches? Nothing more. For example, we don't 
> have a wv2 branch, but we do need knowledge where to find wv2 
> patches. Likewise for HAL.
> 

The issue with hal is a bit more complicated. While the tarball hasn't been
updated since 0.5.14, there have been a number of changes to the git repository
and a number of branches created dealing with suspend/resume issues, etc. I
don't really have much confidence that the old 0.5.14 tarball contains any of
the fixes presently in the git tree. That's why I thought it might take a bit
more than getting a collection of patches together. The other issue is the main
hal.patch is almost as large as the 0.5.14 tarball at present. I know for one,
relying on a 1 meg years old patch is dicey at best.

> Right now we already have a git module called thirdparty. The only 
> submodule now is libreoffice. Add appropriate submodules as needed: 
> wv2, HAL, etc. Add the necessary patches there.
> 

This is a good idea and I think it will work for hal once it is cleaned up. The
thirdparty directory would make an ideal place for patchsets for external
sources. (name is kind of wonky, but works) Something like the following
containing the current patchsets for each package:

thirdparty
  apetag
  hal
  hal-info
  libkarma
  libnjb
  libutempter
  mt-daapd
  musepack-tools
  wv2
  xmedcon

What I would also like to see is 1 generic patch in each directory that is the
culmination of all current patches that are generic to the code for each app.
Not 7 or 10 individual patches per app. The 'wv2-tde.patch', etc.. could serve
as the naming convention for the combined patchsets, with a standard 'patch Np#
-i filename' install requirement.

> Post a wiki article with links to the thirdparty patches.

+1

-- 
David C. Rankin, J.D.,P.E.