lintian overrirede shlib-with-non-pic-codeshlib-with-non-pic-code, was: [SCM] FFmpeg packaging branch, master, updated. debian/0.5+svn20090609-1-22-g6b646aa

[Reinhard Tartler]

Fabian Greffrath <greffrath at leat.rub.de> writes:

> Unfortunately, even with the smallest change that we currently commit to
> the ffmpeg-debian master branch, we divert it more and more from the
> master.extra branch. Even a simple rebase didn't work when I tried it
> out recently...

rebase will "break" all working copies of the other team
members. Morover, you will not be able to 'fast-forward' push to our
repository, so you'd have to override existing revisions. Please avoid
that.

> Is it possible to automatically commit changes to master.extra when they
> get commited to master? This way master.extra would still stay something
> like a static diff against master.

A static diff against master can always be generated by using 'git diff
master..master.extra'. Diffs against the lastest upload from master is
analog: 'git diff debian/$version..master.extra'

> I am asking because it wanted to finaly rip out all the case
> differentiations and references to code stripping from master.extra but
> didn't want to touch it in its current state (i.e. some commits beind
> master that I couldn't fetch up automatically).

I don't think it is worth the efford to keep the HEAD of master
up-to-date in the master.extra branch. Way more efficient is to
regularily merge the latest upload (which is represented by a tag) into
master.extra. This merge *should* go without any conflicts, however if
they are indeed conflicts, they will only appear *exactly once*, as
their resolution is recorded then.

This approach has the obvious drawback that when there are commits in
master that are not uploaded yet, there is no easy way to get them into
master.extra. I see this as a positive feature, as it increases the
preasure to first work on master, get it into shape and uploaded, so
that work on master.extra can continue.

In the case you want to experiment with the ffmpeg-extra and
unuploaded-yet commits, I'd suggest to create a local scratch branch and
merge in the missing revisions from master. If this causes conflicts,
then we probably have divergence that should be fixed in either master
or master.extra.

Coming back to the topic: what's the general feeling of the status of
'master'. Do you feekl it is ready for upload?

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4