Request permission to break always use system libs rule for asc-2.0

Hans de Goede j.w.r.degoede at hhs.nl
Mon Oct 22 18:47:45 UTC 2007


Toshio Kuratomi wrote:
> Hans de Goede wrote:
>> Hi All,
>>
>> I'm currently working on upgrading asc (Advanced Strategic Command) to 
>> 2.0.1.0 When packaging asc-1.16.4.0, I also packaged SDLmm-0.1.8 and 
>> paragui-1.0.4.
>>
> 
> [snip information on SDLmm and paragui being dead upstream.  Bugfixes
>  present in the copies in asc.  Merging of paragui non-trivial due to
>  reformat of the source.]
> 
>> Are there any objections against this?
>>
> The options I see in decreasing order of preference are:
> 
> 1) Get the asc maintainers to take over maintenance of SDLmm and paragui

They have in a way, but since there are no other users and no upstream, they 
are maintaining them in tree, in a sense they have become part of ASC.

> 2) Create paragui/paragui-devel and SDL-mm/SDL-mm-devel packages from 
> the asc source tarball.

To what purpose? There are no other users, if you can name one package out 
there which could be packaged for Fedora which uses either of them I would 
fully agree, which is why I created a seperate package for SDLmm in the first 
place. But there are _no_ other users. Try googling for paragui, the first 2 
links are dead upstream websites then a domain squater, then some old 
mailinglist posts and then we go into rpmsearch hits.

SDLmm, the same the last mailinglist post is from dec 2005!

So I challenge you, give my another (potential) package that needs them and I 
agree.


> 3) Use a private copy of SDL-mm and paragui inside the asc binary rpm.
> 

Which would be the least work, not deviating from what upstream does (wasn't 
our mantra upstream upstream upstream?) and has no downsides.



> If you've explored #1 and are planning on doing #2 I have no objections.
> 
> If you're going to do #3 I'd like to know why you favor it over #2.
> 

See above, there are no users, so its extra work for nothing.

Regards,

Hans




More information about the fedora-devel-list mailing list