Bug 693363

- rpmlint OK
- package must be named according to Guidelines OK
- spec file name must match the base package %{name} OK
- package must meet the Packaging Guidelines OK
- package must be licensed with Fedora approved license OK
- license field must match actual license OK
- text of the license in its own file must be included in %doc OK
- sources must match the upstream source OK
- package MUST successfully compile and build OK
- architecture listed in ExcludeArch MUST have a bug filed in bugzilla OK
- build dependencies must be listed in BuildRequires OK
- handle locales properly with %find_lang macro OK
- shared library files must call ldconfig in %post(un) OK
- packages must NOT bundle system libraries OK
- package must own all directories that it creates OK
- permissions on files must be set properly OK
- package must consistently use macros OK
- package must contain code, or permissable content OK
- large documentation must go in a -doc OK
- %doc must not affect the runtime of the application OK
- header files must be in a -devel package OK
- static libraries must be in a -static package OK
- library files that end in .so (without suffix) must go in a -devel OK
- devel package usually require base package OK
- packages must NOT contain any .la libtool archives OK
- GUI applications must include a %{name}.desktop file OK
- packages must not own files or directories already owned by other packages OK

APPROVED

New Package SCM Request
=======================
Package Name: st
Short Description: A simple terminal implementation for X
Owners: psabata
Branches: f14 f15
InitialCC:

> - packages must not own files or directories already owned by other packages OK

Erm, really?  How did you actually check?  I thought /usr/bin/st might be conflicting and indeed:
  repoquery --whatprovides /usr/bin/st
shows that it is (openstack-swift provides that file already).

Arguably this is an issue in openstack-swift, but at this point it's no safe bet that any two-letter command is non-conflicting.

Please work this out and re-raise the fedora-cvs flag when that's been done.

Marcela, thanks for the review.

Jason, thanks for noticing this.
I've contacted openstack-swift owner. We'll see what could be done here.

Hi Petr: 

Let me ping some of the upstream OpenStack-swift folks and get their input. I'll try and do that today. 

I just reparsed:
http://fedoraproject.org/wiki/Packaging/Conflicts#Conflicting_Files

and that looks remarkably bleak. It appears from looking at version control that st pre-dates at least the open sourcing of swift, though I don't know what the reaction will be regardless. 

Thanks, 

David

(In reply to comment #5)
> Hi Petr: 
> 
> Let me ping some of the upstream OpenStack-swift folks and get their input.
> I'll try and do that today. 
> 
> I just reparsed:
> http://fedoraproject.org/wiki/Packaging/Conflicts#Conflicting_Files
> 
> and that looks remarkably bleak. It appears from looking at version control
> that st pre-dates at least the open sourcing of swift, though I don't know what
> the reaction will be regardless. 
> 
> Thanks, 
> 
> David

Thank you!

If that won't go well, we'll have to stick with 'Conflicts'.

So long story short Petr, Silas Sewell and I have exchanged a few emails, and I think from both Silas and I our POV is: 

* hacking openstack-swift or st to have a different binary results in documentation not working, and fedora specific 'problems' 

* st and openstack-swift are not very likely to both want to be on a single system at once. 

So I think the conflicts idea works at least from the openstack-swift perspective.

My current plan wrt openstack-swift is to introduce this conflicts with openstack-swift 1.3.0, which may be a bit, there are some additional as-of-yet-unpackaged dependencies that need to be introduced to Fedora, so it won't be immediate, but certainly soon, though adding the conflicts to st should resolve the immediate issue I believe. 

Thoughts, comments?? flames??

(In reply to comment #7)
> So long story short Petr, Silas Sewell and I have exchanged a few emails, and I
> think from both Silas and I our POV is: 
> 
> * hacking openstack-swift or st to have a different binary results in
> documentation not working, and fedora specific 'problems' 
> 
> * st and openstack-swift are not very likely to both want to be on a single
> system at once. 
> 
> So I think the conflicts idea works at least from the openstack-swift
> perspective.
> 
> My current plan wrt openstack-swift is to introduce this conflicts with
> openstack-swift 1.3.0, which may be a bit, there are some additional
> as-of-yet-unpackaged dependencies that need to be introduced to Fedora, so it
> won't be immediate, but certainly soon, though adding the conflicts to st
> should resolve the immediate issue I believe. 
> 
> Thoughts, comments?? flames??

Thank you both!

As I see it, openstack-swift upstream don't want to change the binary name 'just because'. Well, we have to (or should) respect their decision.

I'm okay with mutual confict, just wanted some cleaner solution.

--

Updated spec and SRPM:
http://psabata.fedorapeople.org/packages/st/st.spec
http://psabata.fedorapeople.org/packages/st/st-0.1.1-2.fc14.src.rpm
--
--- a/st.spec
+++ b/st.spec
@@ -15,6 +15,8 @@ BuildRequires:  libX11-devel
 BuildRequires:  ncurses
 BuildRequires:  desktop-file-utils
 Requires:       terminus-fonts
+# /usr/bin/st, rhbz#693363
+Conflicts:      openstack-swift
 
 %description
 A simple virtual terminal emulator for X which sucks less.
@@ -44,5 +46,8 @@ desktop-file-install --dir=%{buildroot}%{_datadir}/applications %{SOURCE1
 %{_datadir}/applications
 
 %changelog
+* Mon May 23 2011 Petr Sabata <psabata> - 0.1.1-2
+- We have a conflict with openstack-swift (#693363)
+
 * Mon Apr  4 2011 Petr Sabata <psabata> - 0.1.1-1
 - Initial import

Conflicts should solve it, approved.

Thanks, Marcela.

Setting fedora-cvs? flag again...

Git done (by process-git-requests).

Thanks, Jason.

st-0.1.1-2.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/st-0.1.1-2.fc14

st-0.1.1-2.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/st-0.1.1-2.fc15

st-0.1.1-2.fc14 has been pushed to the Fedora 14 testing repository.

st-0.1.1-2.fc15 has been pushed to the Fedora 15 stable repository.

st-0.1.1-2.fc14 has been pushed to the Fedora 14 stable repository.