Bug#831525: [libretro-mupen64plus] Remove copies of mupen64plus-*

[Sergio benjamim Rocha filho]

Hey G, charle
Take a look at libretro website, they intent to unify all the HLE plugins 
(glide64, rice, glideN64...). In the long goal they'll have only one HLE 
graphic plugin, as well one LLE plugin (which is working right now, it's the 
Vulkan backend), it'll diverge more and more anyway in the future. So if you 
wanna merge it to upstream, good luck, libretro team tried and upstream refused 
a long time ago (when it was more a shallow fork); if upstream is receptive, we 
send back stuff to them directly, like I did with genesis plus gx some days ago.
regards,sergio-br2 

Em Segunda-feira, 22 de Agosto de 2016 6:51, Gianfranco Costamagna 
 escreveu:
 

 control: tags -1 wishlist

> Then please integrate your changes in upstream mupen64plus. Many
> "forks" are now removed from debian (I think mutt-patched is one of
> the recent ones) and now you start to introduce new ones - against the
> Debian policy

this is completely correct, the goal for this package is/should be integrating 
it in
the original mupen64plus.
But until that day, this package has a reason to exist, and to be in Stretch.

the Debian policy in this case is not specifying a "must", but a "should" 
instead
(and we can also discuss if this is a convenience code copy, because the code 
is different)

"Some software packages include in their distribution convenience copies of 
code from other software packages, generally so that users compiling from 
source don't have to download multiple packages. Debian packages should not 
make use of these convenience copies unless the included package is explicitly 
intended to be used in this way.[29] If the included code is already in the 
Debian archive in the form of a library, the Debian packaging should ensure 
that binary packages reference the libraries already in Debian and the 
convenience copy is not used. If the included code is not already in Debian, it 
should be packaged separately as a prerequisite if possible. [30]"

there is no "must" word, so the correct severity is wishlist
(and please don't start a ping/pong severity game, thanks).

Sergio discussed this on debian-mentors, and a few DD agreed that the severity 
is not RC, hence I'm downgrading it right now.

thanks for the bug report, I hope it will be eventually fixed and this package 
removed.

G.


   

Bug#831525: [libretro-mupen64plus] Remove copies of mupen64plus-*

[Gianfranco Costamagna]

control: tags -1 wishlist

> Then please integrate your changes in upstream mupen64plus. Many
> "forks" are now removed from debian (I think mutt-patched is one of
> the recent ones) and now you start to introduce new ones - against the
> Debian policy

this is completely correct, the goal for this package is/should be integrating 
it in
the original mupen64plus.
But until that day, this package has a reason to exist, and to be in Stretch.

the Debian policy in this case is not specifying a "must", but a "should" 
instead
(and we can also discuss if this is a convenience code copy, because the code 
is different)

"Some software packages include in their distribution convenience copies of 
code from other software packages, generally so that users compiling from 
source don't have to download multiple packages. Debian packages should not 
make use of these convenience copies unless the included package is explicitly 
intended to be used in this way.[29] If the included code is already in the 
Debian archive in the form of a library, the Debian packaging should ensure 
that binary packages reference the libraries already in Debian and the 
convenience copy is not used. If the included code is not already in Debian, it 
should be packaged separately as a prerequisite if possible. [30]"

there is no "must" word, so the correct severity is wishlist
(and please don't start a ping/pong severity game, thanks).

Sergio discussed this on debian-mentors, and a few DD agreed that the severity 
is not RC, hence I'm downgrading it right now.

thanks for the bug report, I hope it will be eventually fixed and this package 
removed.

G.



signature.asc
Description: OpenPGP digital signature

Bug#831525: [libretro-mupen64plus] Remove copies of mupen64plus-*

[Charlemagne Lasse]

severity 831525 serious
bye

Then please integrate your changes in upstream mupen64plus. Many
"forks" are now removed from debian (I think mutt-patched is one of
the recent ones) and now you start to introduce new ones - against the
Debian policy

Bug#831525: [libretro-mupen64plus] Remove copies of mupen64plus-*

[Sérgio Benjamim]

Hi,

This is not a valid bug. The libretro port of mupen64plus have many 
changes, it also includes changes in the graphic plugins like rice and 
glide64 and others.


i.e., you can't use the vanilla mupen plugins in the libretro port.

Take a look at the commits in the 
https://github.com/libretro/mupen64plus-libretro


regards,
sergio-br2


On Sun, 17 Jul 2016 00:28:23 +0200 Charlemagne Lasse 
 wrote:

> Source: libretro-mupen64plus
> Version: 2.0+git20160207+dfsg2-1
> Severity: serious
>
> Marked as serious because it is a violation of paragraph 4.13 from the
> Debian Policy.
>
> Debian should not ship the same things twice. So the Debian Games Team
> should decide whether it wants to ship mupen64plus-* or
> libretro-mupen64plus
>
> Maybe it is also possible not to use the included copies and instead
> load the plugins from mupen64plus-*
>
>

Bug#831525: [libretro-mupen64plus] Remove copies of mupen64plus-*

[Charlemagne Lasse]

Source: libretro-mupen64plus
Version: 2.0+git20160207+dfsg2-1
Severity: serious

Marked as serious because it is a violation of paragraph 4.13 from the
Debian Policy.

Debian should not ship the same things twice. So the Debian Games Team
should decide whether it wants to ship mupen64plus-* or
libretro-mupen64plus

Maybe it is also possible not to use the included copies and instead
load the plugins from mupen64plus-*