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

[Toshio Kuratomi]

Hans de Goede wrote:
> 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.
> 
Have you asked upstream if they're willing to make separate 
tarballs/releases for SDLmm and paragui since they are the de facto 
maintainers of those code bases at this point?

>> 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.
> 
> 
That's not great reasoning.  If asc maintained those libraries out of 
tree and made releases as separate tarballs, you'd continue to make 
separate packages, right?  It's not a question of how many consumers 
there are but of how useful the library is outside of the program.

Since these libraries were released outside of the program before and 
you haven't said anything about the build scripts being changed just 
bugfixes and code-formatting I have the impression that they would be 
useful outside of asc.  You could correct me on that by letting me know 
that the asc fixes have made the two code bases dependent on each other 
or some other technical reason that they aren't two separate codebases 
that happen to be maintained in the same tree.

>> 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 a problem is serious enough we do deviate from upstream.  For 
instance, changing a package to build against system libraries is 
certainly something that we do whether or not upstream.  We also will 
take the time to help upstream do the right thing rather than blindly 
packaging what they hand us.  In this case, it sure looks best to me to 
build those libraries from upstream's tarball as system libraries and 
then have the asc programs use those.

The downsides:
* if you make these private libraries of asc you then have all the 
problems of static libraries should another program be created in the 
future that makes use of their own copy of those libraries.

* There's no attempt to coordinate work on the libraries.  Should 
another developer decide they want to build something that uses 
functionality that could be provided by SDl-mm or paragui they'll be 
unaware that there is active maintenance of these libraries occurring 
and will either fork their own copy or reinvent the wheel.

-Toshio