Re: [gentoo-user] linuxtv-dvb-headers gone virtual blocks mythtv overlay

[Alan McKinnon <alan.mckinnon@gmail.com>]

On Fri, 17 Feb 2012 11:39:24 +0100
Raffaele BELARDI <raffaele.belardi@st.com> wrote:

> On 02/17/2012 11:18 AM, Alan McKinnon wrote:
> > On Fri, 17 Feb 2012 09:01:36 +0100
> > Raffaele BELARDI <raffaele.belardi@st.com> wrote:
> >> The change was done in the mythtv overlay
> >> (/usr/local/mythtv_portage/), would that be overwritten by a
> >> resync? I understood that overlay gets updated only when there is
> >> a mythtv update upstream.
> > 
> > It will be overwritten with every layman update/resync
> > 
> > layman will notice that you have a file that is different from the
> > repo and will revert it, and you cannot stop this happening. It
> > does not depend on whether the remote file has changed, it only
> > depends on you locally having a file that is different to the repo.
> > 
> > Seriously, the gentoo docs are full or warning to not do what you
> > did. Use the local overlay, it was designed for exactly this
> > purpose.
> 
> I'm probably oversimplifying because I don't know much about overlays.
> 
> I'm not using layman at all but I am using a local overlay for mythtv.
> From what I understand the 'overlayed' mythtv ebuild is responsible
> for the overlay update though a script installed
> in /etc/portage/postsync.d/ which basically performs a 'git pull'. So
> unless there is a new git snapshot upstream the modified ebuild will
> not get overwritten, correct?

I have no idea what you are talking about actually.

ebuilds do not update themselves, something else does.

All an overlay is, is an alternate bunch of ebuilds laid out in the
same format as the portage tree. Layman is nothing more than a nice
bunch of scripts that automate the install, update and resync aspect of
using them. The process you just described makes no sense to me at all
unless it is some customization you did yourself.

But step back and look at this logically. You have a copy of a file
that gets updated from a repo somewhere. But you are also fiddling
around with the same file and expecting it to all magically just work
without collisions despite having two agents fooling around with it.

Does that strike you as a good idea?

The sane way to do this is to leave the remote repo alone and let it do
it's thing when and how it wants to using layman. You will then always
have an ebuild synced to upstream. Copy the ebuild you feel you need to
modify to PORTDIR_OVERLAY and make your changes there. Portage will use
your customized ebuild in preference to the one from the overlay
(due to priority rules) so all is good. When the ebuild in the git repo
is updated, the version number will be bumped and portage will then use
that one in preference to your local copy (due to version number being
higher). If that ebuild doesn't quite work for you yet, copy it to
PORTDIR_OVERLAY and make your custom changes there. keep doing this,
rinse and repeat, until the upstream repo gets their act together.


-- 
Alan McKinnnon
alan.mckinnon@gmail.com