Spec URL: http://sonkun.fedorapeople.org/SFML/SFML/sfml.spec SRPM URL: http://sonkun.fedorapeople.org/SFML/SFML/sfml-2.0-1.fc19.src.rpm Description: SFML is a portable and easy to use cross-platform multimedia API written in C++. You can see it as a modern, object-oriented alternative to SDL. Fedora Account System Username: sonkun This is a package renaming request. I want to replace the existing SFML package, which is in uppercase, to lowercase. By default, it should have been in lowercase, according the package naming guidelines which mentions how lowercase is preferred unless the upstream explicitly wants to keep the capitals letters. I've talked to the upstream and even he prefers having it in lowercase. I'm also part of the upstream. I joined the SFML team to maintain its Android port and to maintain its Linux packages. It will affect the compat-SFML16 package which won't be compatible with this new one. This old version doesn't need to be kept and is deprecated. If this package has to be kept, it will need to modify the path of the installed files. I had the agreement of the current maintainer of SFML to take over it once renamed. As soon as it's done, I'll submit five new packages, these being the .Net, C, Python, Java and Ruby bindings. Here's the koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5820490
Ah... Why not add virtual provides?
I noticed a typo, I mean I "have" his agreement. > Ah... Why not add virtual provides? Why not a fresh start ? The current package doesn't ship properly SFML files anyways. Would a virtual package pollute the name space ? I mean, will "yum search" show up SFML twice ? Because it might confuse people.
(In reply to Jonathan De Wachter from comment #0) > Spec URL: http://sonkun.fedorapeople.org/SFML/SFML/sfml.spec > SRPM URL: http://sonkun.fedorapeople.org/SFML/SFML/sfml-2.0-1.fc19.src.rpm > Description: SFML is a portable and easy to use cross-platform multimedia > API written in C++. You can see it as a modern, object-oriented alternative > to SDL. > Fedora Account System Username: sonkun > > This is a package renaming request. I want to replace the existing SFML > package, which is in uppercase, to lowercase. This violates the FPG. We mandate the package names to match the tarballs. Like Christopher said, you can add virtual provides, instead.
> This violates the FPG. We mandate the package names to match the tarballs. I'd like to see where this is mentioned in the FPG.
Funny. Your package has no problem with adding virtual provides. I don't know why you want to waste another repo to fix the correct thing. Are there any users get confused with these names? Let's see GeoIP, you can yum search eithor geoip or GeoIP, please tell me if there is something different.
(In reply to Ralf Corsepius from comment #3) > (In reply to Jonathan De Wachter from comment #0) > > This is a package renaming request. I want to replace the existing SFML > > package, which is in uppercase, to lowercase. > This violates the FPG. We mandate the package names to match the tarballs. I quote http://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming "When naming a package, the name should match the upstream tarball or project name from which this software came. In some cases, this naming choice may be more complicated. If this package has been packaged by other distributions/packagers in the past, then you should try to match their name for consistency. In any case, try to use your best judgement, and other developers will help in the final decision." in this case Jonathan is part of SFML team developers, so he have the best reason of why he are doing that > Like Christopher said, you can add virtual provides, instead. As said @cicku, he is right Best Regards
I thought a package was named after the project, not the tarballs the author makes. So if we decide to name our tarballs "simple-and-fast-multimedia-library-2.1.tar.gz", the package name needs to be simple-and-fast-multimedia-library if I get it right. Sorry, I didn't know that following the packaging policy wasn't important. You want another funny fact ? When I type yum search geoip, I get a bunch of geoip packages with different cases and even spelled differently: geoip, GeoIP, Geo-IP. That looks really clean... I'm about to provide 5 bindings which are going to respect the naming policy so I'd like homogeneity across my packages when people type "yum search sfml".
Funny again. Where is "Geo-IP"? It's a Perl module, even jackass can identify what they need. See: http://pkgs.org/search/?keyword=geoip GeoIP is GeoIP, not geoip. So do other distros change the name? Definitely not. See sfml: See: http://pkgs.org/search/?keyword=sfml Yeah, only Fedora use SFML, you should really ask the original packager, why he did this. I support changing its name, but I think it's too late. Already packaged for serveral releases, just add virtual provides is enough.
We've discussed this a bit privately prior to this rename request. There is nothing in the guidelines that mandates using the upper-case project name only. Also, for virtual package names, %_isa is not automatic, so that would be a bit ugly, too. > If this package has been packaged by other distributions/packagers > in the past, then you should try to match their name for consistency. Which has not been done, btw. The review request has not commented on the lower-case package naming used by other dists. The previous review request by a different submitter and a different reviewer did not either, but used lower-case naming.
> I support changing its name, but I think it's too late. > Already packaged for serveral releases, just add virtual > provides is enough. You make it sound as if no other package had been renamed before. ;-) [...] > Provides: SFML = 2.0 > Provides: SFML-devel = 2.0 > Obsoletes: SFML <= 1.6 > Obsoletes: SFML-devel <= 1.6 The SFML-devel Obsoletes/Provides are misplaced here. They belong into the -devel package, of course. Version "<= 1.6" is not high enough, considering that 2.0 has been released before: http://koji.fedoraproject.org/koji/packageinfo?packageID=13119 > %package devel > Summary: Development files for SFML Almost funny. ;-) > %{_libdir}/cmake/* You either need to depend on cmake or include the directory, too: https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function Talking about %_isa. Currently, the dependencies look like: # repoquery --whatrequires --exactdeps SFML derelict-sfml-0:3-13.20130516gitd8aa11d.fc19.i686 derelict-sfml-0:3-13.20130516gitd8aa11d.fc19.x86_64 derelict-sfml-0:3-19.20130624gitdd0de49.fc19.i686 derelict-sfml-0:3-19.20130624gitdd0de49.fc19.x86_64 derelict-sfml-devel-0:3-13.20130516gitd8aa11d.fc19.i686 derelict-sfml-devel-0:3-13.20130516gitd8aa11d.fc19.x86_64 derelict-sfml-devel-0:3-19.20130624gitdd0de49.fc19.i686 derelict-sfml-devel-0:3-19.20130624gitdd0de49.fc19.x86_64 # repoquery --whatrequires --exactdeps 'SFML(x86-64)' SFML-devel-0:1.6-10.fc19.x86_64 SFML-devel-0:2.0-2.fc19.x86_64
(In reply to Michael Schwendt from comment #10) > > I support changing its name, FYI: I do not support changing package names for "letter cases", because all these serve is personal preference and stylishness, which probably originate from an individual's history (e.g. as Debian users) or cultural backgrounds (Some languages don't care much about cases). However in everyday life, cases play a significant role, even in English: "I had some coke" is something entirely different than "I had some Coke". Also, these days, yum is able to handle cases, so the initial argument brought up here is mostly moot: # yum search sfml-devel Loaded plugins: auto-update-debuginfo, langpacks, refresh-packagekit =========================== N/S matched: sfml-devel =========================== SFML-devel.i686 : Development files for SFML SFML-devel.x86_64 : Development files for SFML derelict-sfml-devel.i686 : Header files and libraries for sfml derelict-sfml-devel.x86_64 : Header files and libraries for sfml Name and summary matches only, use "search all" for everything.
This isn't a personal preference, it's the naming policy and upstream 's preference. In my humble opinion, your argument regarding how cases play a significant role in every day life isn't relevant to this context. I think that allowing upper-case was a very bad idea because it's unnecessary and this only introduces confusions and mistakes. Unnecessary because even if there was a clash name among two projects that need to be packaged, we wouldn't want to differentiate them with their case (at least I hope). Confusions and mistakes because it needs the user to remember its case. But here it's not about opinions or being able to find a package, it's about consistencies. For sure, people will find the package he wants, upper-case or not, but he will certainly be pissed off to run "yum search" because people aren't able to be consistent and will find Fedora messy.
> The SFML-devel Obsoletes/Provides are misplaced here. They belong into the -devel package, of course. > > Version "<= 1.6" is not high enough, considering that 2.0 has been released before: http://koji.fedoraproject.org/koji/packageinfo?packageID=13119 Fixed. >> %{_libdir}/cmake/* > >You either need to depend on cmake or include the directory, too: Fixed. > Talking about %_isa. Currently, the dependencies look like: > > # repoquery --whatrequires --exactdeps SFML > derelict-sfml-0:3-13.20130516gitd8aa11d.fc19.i686 > derelict-sfml-0:3-13.20130516gitd8aa11d.fc19.x86_64 > derelict-sfml-0:3-19.20130624gitdd0de49.fc19.i686 > derelict-sfml-0:3-19.20130624gitdd0de49.fc19.x86_64 > derelict-sfml-devel-0:3-13.20130516gitd8aa11d.fc19.i686 > derelict-sfml-devel-0:3-13.20130516gitd8aa11d.fc19.x86_64 > derelict-sfml-devel-0:3-19.20130624gitdd0de49.fc19.i686 > derelict-sfml-devel-0:3-19.20130624gitdd0de49.fc19.x86_64 > > # repoquery --whatrequires --exactdeps 'SFML(x86-64)' > SFML-devel-0:1.6-10.fc19.x86_64 > SFML-devel-0:2.0-2.fc19.x86_64 Should I inform the derelicht-sfml package maintainer ? Thanks for reviewing my package. New Spec URL: http://sonkun.fedorapeople.org/SFML/SFML/sfml.spec New SRPM URL: http://sonkun.fedorapeople.org/SFML/SFML/sfml-2.0-1.fc19.src.rpm New koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5820938
(In reply to Jonathan De Wachter from comment #12) > This isn't a personal preference, it's the naming policy and upstream 's > preference. You are forcing me to do something I've never done in Fedora before: (With my FPC-member hat on) This rename request violates the FPG, because the upstream zip-ball is called SFML, ... Source0: http://www.sfml-dev.org/download/sfml/%{version}/SFML-%{version}-sources.zip ... It therefore MUST NOT be ACCEPTED.
To better inform all involved, could someone give us an idea of how long it will be before upstream does a new release with a lowercase tarball?
[Unrelated to Jon's query...] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Case_Sensitivity | | [...] Keep in mind to respect the wishes of the upstream maintainers. | However, if they do not express any preference of case, you should | default to lowercase naming. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#General_Naming | | If this package has been packaged by other distributions/packagers | in the past, then you should try to match their name for consistency. Upstream does prefer lower-case naming as mentioned at the top of this ticket. Package name is lower-case in other distributions' package collections. That has not been commented on in past review tickets.
I support this, and the conclusions in comment #16 A bit of constructive criticism, I'd recommend changing: Provides: SFML = 2.0 and (in -devel): Provides: SFML-devel = 2.0 to Provides: SFML = %{version}-%{release} and (in -devel): Provides: SFML-devel = %{version}-%{release} respectively.
In reply to Jonathan De Wachter from comment #13) > Should I inform the derelicht-sfml package maintainer ? I'm here.
(In reply to Jon Ciesla from comment #15) > To better inform all involved, could someone give us an idea of how long it > will be before upstream does a new release with a lowercase tarball? Exactly. If these claims about upstream preference are true, all that is required would be them to ship lower-cased tarballs - Fact is, they don't. > (In reply to Jonathan De Wachter from comment #2) > The current package doesn't ship properly SFML files > anyways. Would a virtual package pollute the name space ? They do, but ... I guess you are aware that you will have to provide virtual obsoletes/provides SFML* tags for some time, should this package be renamed? (In reply to Michael Schwendt from comment #9) > We've discussed this a bit privately prior to this rename request. There is > nothing in the guidelines that mandates using the upper-case project name > only. Michael, now you are not playing a fair game. I am very sure you know, it has always been the spirit of the FPG to name packages after the tarballs' names. It is the reason, why Fedora, unlike other distributions, has GeoIP, Coin, perl-Foo-Bar etc. It might be true, this spirit has gone lost in all the legalize the FPG has developed into and with "common sense" having become an unknown term in Fedora, but this "name follows tarball" has always been applied in Fedora.
Jonathan bring this to FPC, i think a discussion outside of the context of this review, will be more beneficial between the parts to reach a consensus. https://fedorahosted.org/fpc/
I've opened a thread on "packaging" list already: https://fedoraproject.org/wiki/Packaging_Committee#Discussions
(In reply to Rex Dieter from comment #17) > I support this, and the conclusions in comment #16 > > A bit of constructive criticism, I'd recommend changing: > > Provides: SFML = 2.0 > and (in -devel): > Provides: SFML-devel = 2.0 > > to > Provides: SFML = %{version}-%{release} > and (in -devel): > Provides: SFML-devel = %{version}-%{release} > respectively. Thank you. Should I do the same for the Obsoletes tag ?
http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages
I've been lazy :p This is fixed. Thank you. New Spec URL: http://sonkun.fedorapeople.org/SFML/SFML/sfml.spec New SRPM URL: http://sonkun.fedorapeople.org/SFML/SFML/sfml-2.0-1.fc19.src.rpm New koji build: http://koji.fedoraproject.org/koji/taskinfo?taskID=5832881
The Summary/Minutes from today's FPC Meeting has been published, and this issue has not been discussed in the meeting, and there haven't been further comments on packaging list (despite the advertisement in the FPC Wiki: "Discussion and decisions can also take place in the packaging mailing list"). So, since Toshio on packaging list had suggested opening a ticket in the FPC trac instance, there it is: https://fedorahosted.org/fpc/ticket/336
And meanwhile, could Jon's question be answered, please? | [...] could someone give us an idea of how long it will be before | upstream does a new release with a lowercase tarball? Also, a statement from another upstream developer would be interesting, too, in order to confirm that there is no preference for a special upper-case spelling. That will also be relevant for the several bindings, which apply several mixed-case spellings.
Hi I am the main developer of SFML. I never mentioned that I preferred upper-case for the original packages, and thus I confirm that lower-case would be preferred for the new ones.
Hello *, from: New Spec URL: http://sonkun.fedorapeople.org/SFML/SFML/sfml.spec ># move FindSFML.cmake to the standard locationg shouldn't the FindSFML.cmake be placed in /usr/share/cmake/Modules and not /usr/lib{,64}/cmake ? Thank you. ps: SFML-2.1 is out http://www.sfml-dev.org/download/sfml/2.1/
That's likely: # rpm -ql cmake|grep Find|grep /usr/share/cmake/Modules|wc -l 166 # rpm -ql cmake|grep Find|wc -l 166 Unfortunately, the FPC got lost again in discussing SCLs in the meeting, not being nice enough to spend a single minute on adding a comment on ticket 336. Even my question there is unanswered for two weeks. That's really disappointing. :-( Speaking of disinterested, the question in comment 15 is still unanswered, too. I've had it refreshed in comment 26.
I am also one of those who prefers to follow tarball naming for package names. Personally I would also suggest to wait for upstream to release a tarball named sfml before proceeding with the renaming. One of the things I appreciate about Fedora packaging is the freedom to use uppercase for package names following upstream tarballs unlike some distros which pretty much seem to assume/force lowercasing...
A couple of things need to happen, since a Rename Request requires a re-review: [sfml.spec] It is unusual to throw away the existing spec file (including its %changelog entries) from Fedora and restart with a completely rewritten one. For the rename request, the new spec file ought to be based on the old spec file and be modified to achieve the renaming: http://pkgs.fedoraproject.org/cgit/SFML.git/plain/SFML.spec Where this would be too much effort, at least the %changelog ought to be copied over to the new spec file. Watch carefully for any details in the spec file and copy them. For example, the old spec file contains a comment on the "License" tag choice. This is missing in the new spec file. The old spec file fixes line delimiters in some %doc files and preserves their timestamps. The new one does it differently without preserving timestamps. Not a big issues, but an unnecessary change. [placement of the CMake module] When moving it to /usr/share/cmake/Modules it would work actually with _this_ package. It does _not_ work with the existing build in the Fedora repos, which moves the headers to a versioned subdir, appends a -2.0 to the libnames and modifies the pkgconfig file appropriately, but doesn't touch the CMake module: http://pkgs.fedoraproject.org/cgit/SFML.git/plain/SFML-2.0-parallel-install.patch [the separate compat-SFML16 package] It is being used: $ repoquery --whatrequires compat-SFML16 compat-SFML16-devel-0:1.6-2.fc20.i686 compat-SFML16-devel-0:1.6-2.fc20.x86_64 dolphin-emu-0:3.5-4.fc20.x86_64 vbam-gtk-0:1.8.0.1159-1.fc19.x86_64 vbam-sdl-0:1.8.0.1159-1.fc19.x86_64 And since the "SFML" package has been modified to be parallel-installable with that 1.6 version, but this new "sfml" package hasn't, this is a problem that must be solved. Has this been discussed yet among the several package maintainers yet? > Provides: SFML = 2.0 > Obsoletes: SFML < 2.0 The "< 2.0" is still too low, considering that Fedora 20 and Rawhide contain SFML-2.0-3.fc20. Hence it must be at least (similarly for the -devel package): Obsoletes: SFML < 2.0-4 As a test, use the rpmdev-vercmp tool or test-install your new builds to see whether they replace the old ones. Currently, they would conflict and refuse to install.
Hi, I'm the maintainer of compat-SFML16 and the guy who wrote the SFML-2.0-parallel-install.patch. I went this route (after discussing this with the current SFML maintainer), so as to not break builds of existing SFML-1.6 using packages. Now that derelict has moved on to using SFML-2.x I see this as less of an issue, and modifying SFML16 rather then 20 to avoid conflicts is fine with me. I see that Michael has already fixed bug 1023572, moving the SFML-1.6 headers to /usr/include/sfml1 . Unfortunately this is not enough to be able to drop SFML-2.0-parallel-install.patch. Files like /usr/lib64/libsfml-audio.so will still conflict when SFML-2.0-parallel-install.patch is dropped. So if we agree to drop that patch, and instead modify compat-SFML16 to avoid the conflict we will need some more changes to compat-SFML16. Once that is done I'm fine with this rename review moving forward and the new sfml package not using SFML-2.0-parallel-install.patch. Jonathan De Wachter asked me by email to also take over maintainership of compat-SFML16 and that is fine by me too. Regards, Hans
The compat-SFML16 package should not have been named a "compat-" package. Historically and typically, compat packages are runtime-only compatibility packages for 3rd party software while the distribution rebuilds its own packages against the latest libs. Ordinary parallel-installable library packages don't add a "compat-" prefix. No other package has picked up compat-SFML16-devel as BuildRequires yet. Only two builds use SFML 1.6 at RPM Fusion, both maintained by the same person, see https://bugzilla.rpmfusion.org/show_bug.cgi?id=3002 I've missed moving the libs (see comment 31) indeed. Moving the headers already breaks existing packages such as "vbam", and I've created a patch for that, but with a non-responsive maintainer at rpmfusion there is no progress/feedback unfortunately. At the same time, SFML 2 CMake script is broken. We need to start somewhere. If there's an idea about where to move the libs (1.6 doesn't use .pc files and doesn't include a reusable cmake script either), please go ahead. It might more productive to retire compat-SFML16, if the two packages at rpmfusion can be ported to SFML 2. That there might be a conflict between the -devel packages some time in the future would not be a big issue IMO, considering that the entire package collection is still not free of conflicts.
(In reply to Michael Schwendt from comment #33) > No other package has picked up compat-SFML16-devel as BuildRequires yet. > Only two builds use SFML 1.6 at RPM Fusion, both maintained by the same > person, see https://bugzilla.rpmfusion.org/show_bug.cgi?id=3002 Right as said I originally went the route I went mainly for derelict, because at the time that was still using sfml-1.6, and I did not want to break it. Still I would like to keep compat-SFML16 around for the rpmfusion users. > I've missed moving the libs (see comment 31) indeed. Moving the headers > already breaks existing packages such as "vbam", and I've created a patch > for that, but with a non-responsive maintainer at rpmfusion there is no > progress/feedback unfortunately. It seems the maintainer was just busy, and has responded to your bug-report over night. > At the same time, SFML 2 CMake script is broken. > > We need to start somewhere. If there's an idea about where to move the libs I've just done a compat-SFML16 build renaming the .so links to libsfml-foo-1.6.so, I'll file patches for the 2 rpmfusion users to use that, just like they need to be patched for the includedir changes. With this changed, I've also dropped my patch from the SFML packages, and moved the cmake script to proper location, fixing the cmake script issue. With this all fixed, this review should now just be a regular rename review without anything special.
$ rpmls -p SFML-devel-2.0-5.fc20.x86_64.rpm |grep -i cmake drwxr-xr-x /usr/lib64/cmake/SFML -rw-r--r-- /usr/lib64/cmake/SFML/FindSFML.cmake As per comment 28, comment 29 and comment 31, that is the wrong location, and CMake doesn't find it there. In /usr/share/cmake/Modules it would work actually. > this review should now just be a regular rename review without anything special. bug 1003569 (non-free fonts is still waiting for a response, too)
(In reply to Michael Schwendt from comment #35) > $ rpmls -p SFML-devel-2.0-5.fc20.x86_64.rpm |grep -i cmake > drwxr-xr-x /usr/lib64/cmake/SFML > -rw-r--r-- /usr/lib64/cmake/SFML/FindSFML.cmake > > As per comment 28, comment 29 and comment 31, that is the wrong location, > and CMake doesn't find it there. > > In /usr/share/cmake/Modules it would work actually. Hmm, tons of other libs also dump their cmake files there, while I've only managed to find one which drops it inside /usr/share/cmake/Modules. I guess we should discuss this with the cmake Fedora packager. > > this review should now just be a regular rename review without anything special. > > bug 1003569 (non-free fonts is still waiting for a response, too) Ah, I had not seen that one, yes we need to fix that. Jonathan, can you get upstream to fix that and release a fixed tarbal in a reasonable time frame ?
%_libdir/cmake/ is for project/package ConfigMake files, whereas SFML only ships a Find*.cmake file.
(In reply to Michael Schwendt from comment #37) > %_libdir/cmake/ is for project/package ConfigMake files, whereas SFML only > ships a Find*.cmake file. Ah, right I did not know that. I'll do another SFML-2.0 build fixing this, as well as the non free font file issue.
If there's still interest in moving forward with this rename request, the remaining item from comment 31 and comment 23 is to present an updated spec and src.rpm for review based on the latest http://pkgs.fedoraproject.org/cgit/SFML.git/tree/ with proper Obsoletes/Provides pairs - possibly considering bug 1033924 (SFML 2.1 upgrade request). This is the only hurdle left for the renaming. ;)
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days