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

[Hans de Goede]

Toshio Kuratomi wrote:
> Hans de Goede wrote:
>>> 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.
> 

Thats not great reasoning either, if we follow that reasoning then all pieces 
of code in applications which may be useful outside of an application should be 
converted into libraries before those programs may pass review. See, this kind 
of "reasoning" is what you get if you insist on stubbornly and blindly 
following the theory of the rules without looking at the practical situation at 
hand.

> 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.

I didn't say anything about buildscript changes because that seemed irrelvant, 
to be honest I didn't expect anyone to object. But no that you ask, the SDLmm 
and paragui configure scripts and config.h have been removed and now the asc 
scripts and config.h get used.

> 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.
>

I keep repeating myself, what is the practical use of splitting them? upstream 
is maintaining them as if they are one code base, there are no known other 
applications which them, not in Fedora, nor outside. All you are doing is 
bringing theoretical arguments, not practical ones.

Why should I have to find out what changed, generate patches, maintain seperate 
buildscripts, etc. For 2 additional packages, each time asc does a new release? 
Where is the sense in that? What is the added value for fellow Fedora 
developers or Fedora users? And since there is no added value I would much 
rather spend my time in some other more usefull way.

>>> 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.
> 

Notice the ".. if .. in the future" in your reasoning, still theoretical. I 
would like to be given some more credit here, I have no problem with splitting 
out the libraries again once another using app turns up. But lets wait till then.

I'm very much in favor of the use system libs rule. For example AFAIK Fedora is 
the only distro that has quake3 and tremulous use the system libjpeg use the 
system libjpeg instead of a ptivate copy. Also I'm trying to find the time to 
work on ripping all patent encumbered stuff out of SDL_sound so that can move 
to Fedora, as the new asc release can use a system SDL_sound if present (and 
will use a stripped down, patent free included copy if not present). But 
unfortunately as my time gets sunk into useless discussions like these, sofar I 
haven't found the time to work on SDL-sound.

> * 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.
> 

And since when is it my task as maintainer to take care of coordination of dead 
upstream packages? If FESco / the FPC start demanding that I'm going to have to 
drop a whole shitload of packages, as quite a few of my packages have a dead 
upstream.

Anyways I'm totally fed up with having discussions like this with the 
bureaucratic powers that control Fedora (woa I feel like I'm Ralf now) either 
the powers that be give me permission to use SDLmm and paragui as included and 
maintained within upstream asc release, or I'll just orphan all 3 of them. I 
refuse to become upstream for 2 libraries backporting fixes from asc each 
release just because some people want to follow the rules as if they are 
something holy. orphaning asc would be a shame as its a great and quite popular 
game, but if that is want the powers that be want, then that is what they will get.

Regards,

Hans