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:
>>>> 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.
> 
But I also say in the next few paragraphs that it depends on whether the 
codebases are separate or not.  Extracting a piece of code from a 
program is not a separate codebase.  Building a library from a library 
which is merely being distributed inside of another project's tarball is 
a different story.

>> 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.
> 
Okay.  So that sounds un-promising.  Does this cripple the ability to 
build shared libraries?

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

I keep telling you, being able to reuse the code.

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

I took a highly superficial look at the layout of the source.  Upstream 
is not quite to the point where they are maintaining them as one 
codebase.  They have a libs directory in which they have all of these 
third party libraries tucked.  I didn't look at the separately packaged 
paragui or SDLmm so I don't know how crippled their buildsystems are; 
I'm depending on you as the maintainer to tell me that.

> 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.
>
Either you're misreading me or I'm misreading you.  I've never asked you 
to find out what changed or generate patches.  I've never asked you to 
maintain separate buildscripts although I have asked you whether the 
libraries were still buildable as separate entities.  I'm not asking you 
to continue maintaining three source packages for asc, paragui, and 
SDLmm.  I'm asking you to:

1) Ask the asc maintainers if they'd like to maintain paragui or SDLmm 
upstream.  This is a benefit to the opensource community as a whole if 
they want to do that since someone who needs that functionality won't 
come along later and find that it's no longer possible to separate asc 
from these libraries. This is not something that requires any long term 
effort on your part.  You ask, they refuse, you proceed to package 
everything from the asc tarball.

2) make a quick estimate of whether the paragui and SDLmm sources have 
been so integrated with the asc sources that it's not feasible to build 
multiple rpms from the asc srpm for those libraries.  If it is possible, 
you stop having to maintain three separate spec files.  You stop having 
to push three srpms through the buildsystem.  You stop having to 
generate diffs between the fixed source in the asc source tree and the 
old-never-to-be-updated tarballs from the "official" download 
repository.  These are the benefits of doing this over the state that 
you're in now.  You would still have three binary rpms and the separate 
%files section inside the [single] spec file to manage that so it's not 
as easy as your proposal but it removes the gripes you had with the 
status quo.

Further note that I am not demanding that you follow this plan.  I am 
asking you to tell me if you've considered it and whether it is 
workable.  If you say "the source is all thrown into one directory where 
it's impossible to separate" or "patching the buildscripts to cleanly 
build dynamic libraries will take as long as porting to separate specs 
would have" then I'll know that you had a look at this possibility and 
decided it wasn't worthwhile.

>>>> 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.
> 
If it's hard to split out the libraries now because upstream decided 
that it was extraneous to have separate build scripts, how easy is it 
going to be to split them out three releases from now when the 
maintainers have decided they don't need two versions of a function to 
copy memory or two logging functions or two variables that turn on 
debugging?  If you ask upstream if they would like to maintain the 
packages separately and they say yes, you halt that process and keep 
these libraries alive.  If you don't and those libraries end up 
integrated into the main app then the community loses the ability to 
reuse the code.

And yes, in one respect you can't know what the future will bring but 
it's also not something that can "wait till then." to find out.  The act 
of asking upstream asc if they are willing to become the maintainers of 
the paraguia nad SDLmm libraries will let them know that the 
separability of the libraries is valuable even if they are unwilling to 
actually do the work of packaging them separately.

> 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.
> 
It's not.  But it's within the realm of your responsibilities to try and 
shift the burden onto someone else :-).  asc is plainly maintaining the 
code.  Find out if they're willing to go one step further and maintain 
the code as libraries rather than just a piece of asc.

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

I'd be fed up too if I was standing in your shoes and saw things that 
way.  But the way I see it,  1) you gave an outline of a plan for 
dealing with a dead upstream, 2) I proposed two alternative plans that 
had most of the benefits of your plan, 3) you jump on my case and accuse 
me of forcing you to do something unreasonable.

Once again, I've made no requirements of you.  I've asked you to find 
out if upstream would be willing to do more work.  I've asked you to 
evaluate whether continuing to package the code as libraries but from 
within the asc srpm is feasible.

If you've done the first and the results of the second are that it's an 
unreasonable amount of work then I have no complaints.  If you refuse to 
do the first and don't look into the second I still won't have a 
bugzilla-worthy grievance with your plan (your first message was 
perfectly clear on how dead the upstreams were). I will just be slightly 
peeved that people request comments on their ideas without the 
expectation that they'll have to reevaluate their ideas rather than just 
blindly defending them.

Sincerely,
-Toshio