Currently, mythtv upgrades take away the execute permission of the scripts in /usr/share/mythtv/contrib/, which needs to be set manually every time. e.g. I have set the execute perm on mythrename and it got overwritten with the install of the new package and the 'x' permission got removed. The result was that auto rename user job was not able to run. It can lead to subtle problems with the user's mythtv experience. The request is that upgrades should keep their current permissions in /usr/share/contrib/*.
We never make these scripts executable. The proper thing to do would be for you to copy them to /usr/local/bin and execute them from there.
only problem is that I have to do that every time (more painful is I have to remember to do it, and it break many of my recordings if I forget). I was wondering if ebuild could provide that support. All it has to do is to check which existing files in /usr/share/mythtv/contrib/ have 'x' permission set and chmod +x for those files in "${D}"usr/share/mythtv/contrib/. I can attach a patch if you want.
No. We never mark any files in /usr/share/${P}/contrib as executable. These contrib'd have never changed in between SVN snapshots. If you copy the file once from there from the very first 0.20 release, it will be identical to the file in 0.20-p12884. Just copy it once, you don't have to keep remembering to do it.
(In reply to comment #3) > No. We never mark any files in /usr/share/${P}/contrib as executable. but user did. And there is no reason to maintain it like that, if adds useful value for the end user. I can clearly see that a 'docontrib' is required which will do this job for many packages. > contrib'd have never changed in between SVN snapshots. If you copy the file > once from there from the very first 0.20 release, it will be identical to the > file in 0.20-p12884. that's not good logic. We don't know when it will change. old copy may even corrupt the db if its not kept in sync because the logic might have changed completely. I typically link the required files in /usr/local/bin, not copy them. I am not reopening because it gets annoying pretty quick but I will be waiting on your thoughts on 'docontrib' because its a generic problem affecting other packages as well.
> And there is no reason to maintain it like that ...And there is no reason not to maintain it like that...:-)
docontrib would have to be a Portage add-on.
