Bug 442714 - Review Request: satsolver - Satisfiability Solver library which can be used to compute inter-package dependencies.
Review Request: satsolver - Satisfiability Solver library which can be used t...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
: Reopened
: 729199 (view as bug list)
Depends On:
Blocks: 447738 447740 458254
  Show dependency treegraph
 
Reported: 2008-04-16 08:36 EDT by Lorenzo Villani
Modified: 2011-12-16 19:22 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-12-16 19:21:09 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lorenzo Villani 2008-04-16 08:36:29 EDT
Spec URL: http://rpm.binaryhelix.org/specs/libs/sat-solver.spec
SRPM URL: http://rpm.binaryhelix.org/sat-solver-0.0.27-20080416svn.fc9.src.rpm
Description: sat-solver is a Satisfyability Solver library which can be used to compute inter-package dependencies.
Comment 1 Lorenzo Villani 2008-05-20 14:22:07 EDT
SPEC URL: http://rpm.binaryhelix.org/SPECS/libs/sat-solver.spec
SRPM URL: http://rpm.binaryhelix.org/SRPMS/sat-solver-0.0.33-1.fc9.src.rpm

* Tue May 20 2008 Lorenzo Villani <lvillani@binaryhelix.net> - 0.0.33-1
- Version bump
Comment 2 James Bowes 2008-06-09 08:56:03 EDT
Building on x86_64 gives the following error during rpmbuild:

error: Installed (but unpackaged) file(s) found:
   /usr/lib/zypp/zypp-query-pool
Comment 3 James Bowes 2008-06-09 08:58:49 EDT
Sorry, the above comment should have been on libzypp, not sat-solver.
Comment 4 Lorenzo Villani 2008-06-09 13:50:56 EDT
SPEC URL: http://rpm.binaryhelix.org/SPECS/libs/sat-solver.spec
SRPM URL: http://rpm.binaryhelix.org/SRPMS/sat-solver-0.9.0-1.fc9.src.rpm

* Mon Jun 09 2008 Lorenzo Villani <lvillani@binaryhelix.net> - 0.9.0-1
- Version bump
Comment 5 Jochen Schmitt 2008-06-09 14:53:29 EDT
Good:
+ Local build works fine on x86_64
+ Rpmlint on source package is quite
+ Consistent macro usage
+ package use a OSS license
+ Tar archive in the package matches with upstream
  (md5sum: 52bc1b0309812eead630f8dfe795c923)
+ Rpmlint is quite on sat-solver package
+ File permissions seems ok.
+ Package seems not to have files own by other packages.
+ Local install and uninstall works fine.
+ Package build fine in mock (xu6_64, ppc64 and ppc, devel)


Bad:
- %{_includedir]/satsolver should be own by the package
- Package should not contains static libraries
- Package doesn't contains license text, but upstream package contains a
  verbatin copy of the license.
- Rpmlint complaints on devel package:
  $ rpmlint sat-solver-devel-0.9.0-1.fc9.x86_64.rpm
sat-solver-devel.x86_64: W: no-documentation
- Package seems not to use $RPM_OPT_FLAGS

Questions:
? Why you remove the testsuite. From my point of view this may be helpful to
ensure the QA of the package
Comment 6 Lorenzo Villani 2008-06-09 16:23:49 EDT
Before uploading a new version of the package I need something to be explained:

Bad things:
- %{_includedir}/satsolver: As far as I know, %{_includedir}/satsolver/* gives
ownership to directory-contained files
- static libraries: as far as i know, upstream build system (based on cmake)
only produces static library archives and not shared objects and it seems that
other packages depending on this library statically link the library in their
final executable
- verbatim copy of the license: I included that in both packages using %doc
- rpmlint warning with sat-solver-devel: the inclusion of the verbatim copy of
the license should fix this
- $RPM_OPT_FLAGS: This is due to usage of cmake, afaik, using
-DCMAKE_BUILD_TYPE=FEDORA is sufficient, I added that to the cmake line

And now the questions:
I removed the *huge* testsuite (nearly 50MiB of stuff -compressed-) just to save
bandwidth (yes, I'm lazy), If needed I can keep the testsuite inside the tarball
but this will make the review process much slower because i'll have to upload
~100MiB of compressed tarballs (~50MiB of .src.rpm and ~50MiB of packaged snapshot).

Side notes:
As far as I know both sat-solver, libzypp and zypper can be retrieved only from
upstream' subversion (or by 'extracting' source tarball from SuSE' .src.rpm) so
the source archive is just a local subversion checkout with SCM directories
stripped out (ie: tar'ed using --exclude-vcs)
Comment 7 Lorenzo Villani 2008-06-17 06:12:26 EDT
A reviewer assigned this package to himself, then he didn't reply to my questions.

Releasing the package and restoring the fedora-review flag to empty value.
Comment 8 Dan Horák 2008-06-17 06:50:39 EDT
Reviewing a package is a volunteer process, so you cannot expect that there are
no delays in the communication. So removing a reviewer is at least unpolite.

Now some answers
- %{_includedir}/satsolver - this includes both the directory and the files in
the directory (and any deeper hierarchy), so use it
- $RPM_OPT_FLAGS - there should be a way how to pass own CFLAGS into the compile
process done with cmake, I think/hope :-)
- static libraries - then you should investigate, how to enable building of
shared libraries, using static libs is allowed only in very very special cases
Comment 9 Lorenzo Villani 2008-06-17 06:58:39 EDT
If I remember correctly he assigned then de-assigned the bug to himself (or he
didn't assign the bug to himself at all!) but he left the fedora-review flag to
'?'. The reviewers guidelines state that the reviewer must set fedora-review to
'?' AND assign the bug to himself. This bug was not assigned to anybody but the
flag was set to '?', as a consequence I restored the default value for
fedora-review flag.
Comment 10 Jason Tibbitts 2008-06-18 16:33:17 EDT
The "Show Bug Activity" link should tell you everything you need to know about
the history of this ticket.  As far as I can tell, this ticket has never been
assigned to anyone and Jochen isn't even CC'd on this ticket so he wouldn't see
any of the remarks.

Note that we do have some cmake information:
http://fedoraproject.org/wiki/Packaging/cmake

I would not approve this package without the test suite being included and run
at build time unless that's just not possible.
Comment 11 Dan Horák 2008-06-18 17:38:45 EDT
Yes, I should check the bug history and not blindly trust the comment #7. But I
think all my points are still valid. Our Wiki has a lot of answers for technical
questions. And I have a personal experience with Jochen as reviewer and I know
that it can take weeks before he returns to the review.

The tests could be perhaps omitted for package iterations that should clean the
general packaging issues but then they should be added back. Reduced size can
really help both sides when they are using e.g. ADSL. But I agree with Jason -
if they can be run, they must be included.
Comment 12 Lorenzo Villani 2008-06-19 09:19:41 EDT
I can include them and remove that patch that disables the test suite at import-I can include them and remove that patch that disables the test suite at import-time, if needed
Comment 13 Lorenzo Villani 2008-06-19 09:26:57 EDT
Uhm, sorry for the weird comment.. it seems that konqueror4 is not much usable.
Comment 14 Lorenzo Villani 2008-06-19 14:50:40 EDT
SPEC URL: http://rpm.binaryhelix.org/SPECS/libs/sat-solver.spec
SRPM URL: http://rpm.binaryhelix.org/SRPMS/sat-solver-0.9.0-3.fc9.src.rpm

* Thu Jun 19 2008 Lorenzo Villani <lvillani@binaryhelix.net> - 0.9.0-3
- Using %%cmake properly
- Proper handling of %%{_includedir}/satsolver

Comment 15 Terje Røsten 2008-06-22 16:01:16 EDT
If you please can fix the static libs issue (ping upstream about the problem?),
I would do a proper review of this package (and rest of the zypper stack (which
seems in pretty good shape by the first brief look)).

Comment 16 Lorenzo Villani 2008-06-24 06:33:55 EDT
I sent an email to upstream' development mailing list but I didn't get any
answer. What are we going to do if they don't respond?
Comment 17 Lorenzo Villani 2008-06-24 10:24:13 EDT
Upstream says that they're doing such way because of the still unstable API.
Since they're stabilising the API they say that they will be providing shared
libraries in the near future.
Comment 18 Lorenzo Villani 2008-07-05 05:47:11 EDT
SPEC URL: http://rpm.binaryhelix.org/SPECS/libs/sat-solver.spec
SRPM URL: http://rpm.binaryhelix.org/SRPMS/sat-solver-0.9.2-1.fc9.src.rpm

* Sat Jul  5 2008 Lorenzo Villani <lvillani@binaryhelix.net> - 0.9.2-1
- Version bump (aligned to upstream stable version)
Comment 19 Terje Røsten 2008-07-05 09:31:05 EDT
> Upstream says that they're doing such way because of the still unstable API.
> Since they're stabilising the API they say that they will be providing shared
> libraries in the near future.

If you must use static libs, then at least follow the guidelines:
 
 https://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries

Add Provides for sat-solver-static and add 
Buildrequires: sat-solver-static to libzypp/zypper packages.

When package is included open a bug against the package regarding the
static libs issue.



Comment 20 Lorenzo Villani 2008-07-05 10:00:02 EDT
SPEC URL: http://rpm.binaryhelix.org/SPECS/libs/sat-solver.spec
SRPM URL: http://rpm.binaryhelix.org/SRPMS/sat-solver-0.9.2-2.fc9.src.rpm

* Sat Jul  5 2008 Lorenzo Villani <lvillani@binaryhelix.net> - 0.9.2-1
- provide sat-solver-static
Comment 22 Lorenzo Villani 2008-08-07 10:44:38 EDT
SPEC URL: http://omploader.org/vbm95/sat-solver.spec
SRPM URL: http://omploader.org/vbm96/sat-solver-0.9.4-2.fc9.src.rpm

* Thu Aug  7 2008 Lorenzo Villani <lvillani@binaryhelix.net> - 0.9.4-2
- Removed link to source tarball, it is not needed. Upstream distributes
  sat-solver, libzypp and zypper using a branched subversion tree, the
  tarball which comes with the SRPM is just an exported subversion checkout
Comment 23 Pavel Alexeev 2008-08-07 21:06:19 EDT
By URL in spec - http://en.opensuse.org/Libzypp/Devel I can't found any reference to sat-solver.
Comment 24 David A. Wheeler 2008-08-07 21:38:53 EDT
I'm glad to see this! Two quick notes:

miniSAT, another SAT solver that's used by several other programs, is here:
 https://bugzilla.redhat.com/show_bug.cgi?id=453701

"sat-solver" is a really generic name; it's quite likely that Fedora will end up with several competing SAT solvers.  Shouldn't this SAT solver's package name be something a little more specific, like "libzypp-sat-solver"?  That would leave "sat-solver" as a generic name (one that might, in the future, resolve to whatever default SAT solver the user desires, a la Java implementations).
Comment 25 David A. Wheeler 2008-08-07 21:58:57 EDT
In the "minisat2" package I added a small test case file, which _is_ satisfiable.  This would take a trivial amount of space, if you don't want to include a massive test suite.  It doesn't stress the solver, but it's a reasonable "smoke test" to see if the solver can run:


c
c start with comments
c
c 
p cnf 5 3
1 -5 4 0
-1 5 3 4 0
-3 -4 0
Comment 26 Michal Schmidt 2008-08-18 19:49:35 EDT
Do you really need to specify 'Requires:  expat rpm zlib'? RPM is able to pick dependencies on shared libraries automatically.

I'm not a native speaker, but I'm pretty sure the word is spelled 'satisfiability', not 'satisfyability' (Wikipedia and Googlefight confirm it).
Comment 27 Lorenzo Villani 2008-08-20 09:40:04 EDT
@Pavel Alexeev
I'm sorry, the real URL is: http://en.opensuse.org/Libzypp/Sat_Solver

@David A. Wheeler
sat-solver is the upstream name. I just packaged it with it's original name. But I'm willing to change its name. Regarding the smoke test, I'll add that ASAP, it's more convenient than the huge test suite.

@Michal Schmidt
I'll remove that dependencies in 'Requires' and fix the spelling issues

I am on vacation, it'll require some time to get the issues fixed. Please be patient and thanks for the interest :-)
Comment 28 Lorenzo Villani 2008-08-24 15:20:03 EDT
SRPM URL: http://omploader.org/vcDdi/sat-solver-0.9.4-3.fc9.src.rpm
SPEC URL: http://omploader.org/vcDdj/sat-solver.spec

* Sat Aug 23 2008 Lorenzo Villani <lvillani@binaryhelix.net> - 0.9.4-3
- removed useless requires
- Added a rpm database corruption patch
- Use correct URI
Comment 29 Lorenzo Villani 2008-08-25 11:04:05 EDT
If anyone wants to try the latest package with the included patch...
It *should* fix a bug where yum, when used after zypper (or vice-versa) corrupt the RPM database. In particular it seems to not initialize the db cursor correctly.
Please note that you should recompile libzypp and zypper against this version of the package. I'm testing it too, if no corruption happens in 2 days I'll assume that the issue has been fixed.
Comment 30 Lorenzo Villani 2008-08-25 11:15:25 EDT
SRPM URL: http://omploader.org/vcDk3/sat-solver-0.9.4-4.fc9.src.rpm
SPEC URL: http://omploader.org/vcDk4/sat-solver.spec

Nothing exceptional, only fixed the mispelled word.
Comment 31 Debarshi Ray 2008-09-26 01:47:17 EDT
So is anyone interested in taking over this review?

Lorenzo, are you sponsored and part of the packager group? I could not locate you on this list: https://admin.fedoraproject.org/accounts/group/members/packager?search=*
Comment 32 Mamoru TASAKA 2008-09-26 01:59:21 EDT
(In reply to comment #31)
> Lorenzo, are you sponsored and part of the packager group? 

Lorenzo has "arbiter" FAS name is sponsored by spot.
Comment 33 Lorenzo Villani 2008-09-26 09:14:21 EDT
I'm still willing to get the package in Fedora, the above links *should* still point to srpm and specfile, if not just tell me. Please report if there's anything wrong with the package. I got no responses for a long time but I don't want to give up ;-)
Comment 34 Debarshi Ray 2008-10-15 15:32:22 EDT
MUST Items: 

OK - rpmlint is clean
OK - follows Naming Guidelines
OK - spec file is named as %{name}.spec

xx - package does not meet Packaging Guidelines
    + The Source0 tag should have a valid URL pointing to the upstream release
      tarball. This is an important requirement. In case upstream does not
      provide any such tarball, the Spec should have a comment above the
      Source0 tag describing how the sources were obtained to create the
      package. See:
      https://fedoraproject.org/wiki/Packaging/SourceURL
    + Could you throw some light on why it is a problem to build the language
      bindings on Fedora? Is it because of the ruby-rpm breakage in Rawhide?
    + Please do not strip the test-suite, if it is not absolutely necessary.
      Laziness arising out of needing to upload the SRPM several times is not
      a valid reason. :-)
    + It is not really necessary to create %{_target_platform}. See:
      http://fedoraproject.org/wiki/Packaging/cmake#Specfile_Usage
    + To preserve timestamps you could consider using:
      make install INSTALL="%{__install} -p" DESTDIR=%{buildroot}
    + Please add a comment in the Spec to document the rationale for shipping
      static libraries.
    + You could consider shipping the other files in the doc/ sub-directory as
      %doc. However shipping doc/PLANNING and doc/README in both the main
      package and the -devel sub-package is redundant.

OK - license meets Licensing Guidelines
OK - License field meets actual license
OK - upstream license file included in %doc
OK - spec file uses American English
OK - spec file is legible

?? - sources might not match upstream sources
    + As noted earlier, please document how the sources were obtained. Place a
      comment above the Source0 tag for this.

xx - package does not build successfully
    + sat-solver-no-bindings.patch does not apply cleanly and causes a build
      failure in Rawhide, which uses '/usr/bin/patch -s -p0 --fuzz=0'. See:
      http://koji.fedoraproject.org/koji/getfile?taskID=882707&name=build.log

?? - ExcludeArch not needed

?? - missing build dependencies
    + Can not verify because package fails to build.

OK - no locales

xx - %post and %postun should not invoke ldconfig
    + Since shared libraries are not being shipped, invocation of
      /sbin/ldconfig is not needed and should be removed.

OK - package is not relocatable
OK - missing dependency on package that creates directory
OK - no duplicates in %file
OK - file permissions set properly
OK - %clean present
OK - macros used consistently
OK - contains code and permissable content
OK - -doc is not needed
OK - contents of %doc does not affect the runtime
OK - header files in -devel
OK - static libraries in -static package
OK - no pkgconfig files
OK - no shared library files

OK - -devel does not require base package
    + Only static libraries are provided as part of the -devel or -static
      package. Base package consists of only executables.

OK - no libtool archives
OK - %{name}.desktop file not needed
OK - does not own files or directories owned by other packages
OK - buildroot correctly prepped
OK - all file names valid UTF-8

SHOULD Items:

OK - upstream provides license text
xx - no translations for description and summary

xx - package does not build in mock successfully
    + As noted above, package fails to build in Rawhide.

?? - package builds on all supported architectures

?? - package functions as expected
    + Other components of the Zypper stack are needed to verify functionality.

xx - scriptlets are not sane
    + As noted above, scriptlets are not needed and should be removed.

OK - subpackages other than -devel are not needed
    + -devel provides a -static package.

OK - no pkgconfig files
OK - no file dependencies
Comment 35 Lorenzo Villani 2008-10-16 08:16:01 EDT
SPEC URL: http://fedorapeople.org/gitweb?p=arbiter/public_git/rpm.git;a=blob_plain;f=libs/sat-solver/sat-solver.spec;hb=master
SRPM URL: http://fedorapeople.org/~arbiter/srpm/sat-solver-0.9.5-1.fc10.src.rpm
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=884098

* Thu Oct 16 2008 Lorenzo Villani <lvillani@binaryhelix.net> - 0.9.5-1
- Comments on source0 origin
- Removed no-bindings patch
- Added perl and python bindings
- rpm 4.5.90 patch
- Test suite not stripped and enabled (recompressed tarball
  using bzip2 to save space and bandwidth)
- Preserve timestamp when installing
- Rationale about static libs
- Removed unneeded scriptlets
- Add other documentation to the main package
- Remove redundant documentation files from other packages
Comment 36 Debarshi Ray 2008-10-21 00:22:21 EDT
+ RPMLint is not clean on SRPM:

[rishi@freebook SOURCES]$ rpmlint ../SRPMS/sat-solver-0.9.5-1.fc10.src.rpm 
sat-solver.src: W: mixed-use-of-spaces-and-tabs (spaces: line 3, tab: line 17)
sat-solver.src: W: strange-permission sat-solver.spec 0775
sat-solver.src: W: strange-permission sat-solver-db-corruption-fix.patch 0775
1 packages and 0 specfiles checked; 0 errors, 3 warnings.
[rishi@freebook SOURCES]$

RPMLint is not clean on build sub-packages:

[rishi@freebook SPECS]$ rpmlint sat-solver-perl
sat-solver-perl.x86_64: E: description-line-too-long The sat-solver-perl package contains libraries and perl modules to be used inside
1 packages and 0 specfiles checked; 1 errors, 0 warnings.
[rishi@freebook SPECS]$ rpmlint sat-solver-python
sat-solver-python.x86_64: E: description-line-too-long The sat-solver-python package contains libraries and python modules to be used inside
1 packages and 0 specfiles checked; 1 errors, 0 warnings.
[rishi@freebook SPECS]$

Pretty simple actually. Just replace the tab with equivalent number of spaces on line 17 of sat-solver.spec, and make sure that the files in the SRPM have a permission of 0644. Lines in the description should not exceed 80 characters.

+ Is this package not meant for Fedora 9? The sat-solver-0.9.5-rpm4.5.90.patch patch broke the build on my Fedora 9 system. In case it is only meant for Fedora 10 and above, you could add a versioned dependency on rpm-devel (BuildRequires) and rpm-libs (Requires) to enforce this.
Comment 37 Debarshi Ray 2008-10-21 00:30:19 EDT
According to the Naming Guidelines, package names of Python modules should be prefixed with "python-" or "py". See: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28python_modules.29

In this case you can use:
%package -n     python-%{name}
...
%description -n python-%{name}
...
%files -n python-%{name}

Similarly for the Perl sub-package consult: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Addon_Packages_.28perl_modules.29
Comment 38 Debarshi Ray 2008-12-28 12:17:59 EST
Ping?
Comment 39 Lorenzo Villani 2008-12-28 19:50:15 EST
SPEC URL: http://fedorapeople.org/gitweb?p=arbiter/public_git/rpm.git;a=blob;f=libs/sat-solver/sat-solver.spec;hb=HEAD
SRPM URL: http://fedorapeople.org/~arbiter/srpm/sat-solver-0.9.6-1.fc10.src.rpm

* Sun Dec 28 2008 Lorenzo Villani <lvillani@binaryhelix.net> - 0.9.6-1
- 0.9.6
- sat-solver-perl -> perl-sat-solver
- sat-solver-python -> python-sat-solver
- fix weird .spec file permissions
- fix mixed use of spaces and tabs
- depend on rpm 4.6.0 (ie: build on Fedora 10 only)
Comment 41 Lorenzo Villani 2009-01-26 09:26:56 EST
Closing the request until upstream makes the necessary changes to libzypp to support RPM 4.6.
Comment 42 Lorenzo Villani 2009-12-16 11:59:15 EST
SPEC: http://gitorious.org/lvillani/specs/blobs/master/zypp/sat-solver/sat-solver.spec
SRPM: http://fedorapeople.org/~arbiter/sat-solver/


Notes: 
- reopening since the whole ZYpp stack seems now usable with rpm >= 4.6.0
- rpmlint:
[lvillani@enterprise SRPMS]$ rpmlint ../RPMS/x86_64/sat-solver{,-devel,-doc,-debuginfo}-0.14.11-1.fc12.x86_64.rpm ../RPMS/x86_64/{perl,python}-sat-solver-0.14.11-1.fc12.x86_64.rpm ./sat-solver-0.14.11-1.fc12.src.rpm ../specs/zypp/sat-solver/sat-solver.spec 
7 packages and 1 specfiles checked; 0 errors, 0 warnings.
Comment 43 Pavol Rusnak 2010-03-24 18:38:34 EDT
Please have in mind that sat-solver is highly optimized for solving package dependencies. It is also a _static_ library which is being linked into libzypp and used nowhere else (yet).
Comment 44 Lorenzo Villani 2010-03-30 05:44:46 EDT
(In reply to comment #43)
> Please have in mind that sat-solver is highly optimized for solving package
> dependencies. 

Are you suggesting me to use a different package name...

> It is also a _static_ library which is being linked into libzypp
> and used nowhere else (yet).

... and to build sat-solver along with libzypp source package? (I don't know if I can do that).
Comment 45 Rahul Sundaram 2010-04-23 08:00:39 EDT
It fails to build on Fedora 13 because of the ld change

---

/usr/bin/ld: ../ext/libsatsolverext.a(repo_rpmdb.o): undefined reference to symbol 'pgpPrtPkts'
/usr/bin/ld: note: 'pgpPrtPkts' is defined in DSO /usr/lib/librpmio.so.1 so try adding it to the linker command line
/usr/lib/librpmio.so.1: could not read symbols: Invalid operation
collect2: ld returned 1 exit status

---

Details on how to fix is at 

http://lists.fedoraproject.org/pipermail/devel-announce/2010-February/000563.html
Comment 47 Rahul Sundaram 2010-05-22 16:00:51 EDT
zypper and lib-zypper has a BR on sat-solver-static but I don't find it in your mock build.
Comment 48 Lorenzo Villani 2010-05-23 09:52:12 EDT
(In reply to comment #47)
> zypper and lib-zypper has a BR on sat-solver-static but I don't find it in your
> mock build.    

It is a "virtual" Provide from sat-solver-devel (http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries)
Comment 49 Jan Engelhardt 2010-08-05 10:12:35 EDT
In response to comment #27:
>sat-solver is the upstream name. I just packaged it with it's original name.

Upstream isn't always the best :)  In openSUSE itself, the package is called libsatsolver (not libsat-solver nor sat-solver nor satsolver). Its subpackages are also called perl-satsolver (not perl-sat-solver). In that regard, sat-solver with a dash seems to be a relic name of the repository.
Comment 50 Lorenzo Villani 2010-08-20 13:49:56 EDT
(In reply to comment #49)
> 
> Upstream isn't always the best :)  In openSUSE itself, the package is called
> libsatsolver (not libsat-solver nor sat-solver nor satsolver). 

It's called libsatsolver because they usually prefix library packages with "lib", IIRC.

> [...]
> In that regard, sat-solver with a dash seems to be a relic name of the
> repository.

The most correct name is, probably, "satsolver". It's a generic (and probably misleading) name. Maybe I can rename this package to "satsolver" now and, should some conflict arise, rename it again later.

Suggestions welcome (-:
Comment 51 Jan Engelhardt 2010-08-20 14:06:01 EDT
>It's called libsatsolver because they usually prefix library packages
>with "lib", IIRC.

So, by that very logic, it should be "satsolver-libs" in Fedora.

(Though the Fedora naming scheme always felt strange. What will be done if you need two versions. libfoo1 and libfoo2 work out, but foo-libs and foo-libs - you see the clash.)

> "satsolver". It's a generic

Feel free to suggest; discussion was already started on similar hot topic http://lists.opensuse.org/opensuse-buildservice/2010-07/msg00179.html
Comment 52 Lorenzo Villani 2010-08-23 06:48:46 EDT
(In reply to comment #51)
> 
> So, by that very logic, it should be "satsolver-libs" in Fedora.
> 

AFAIK, the "-libs" suffix is used when an application also happens to ship libraries usable by 3rd parties. So for pure libraries only "name" and "name-devel" are necessary, IIRC.

> Feel free to suggest; discussion was already started on similar hot topic
> http://lists.opensuse.org/opensuse-buildservice/2010-07/msg00179.html

Following the "if it ain't broken, don't fix it" motto, I'd like to push this package as "satsolver" (not "sat-solver") and rename it only if needed.
Comment 53 Lorenzo Villani 2010-08-29 08:48:39 EDT
SPEC URL: http://github.com/lvillani/RPMs/raw/master/satsolver/satsolver.spec
SRPM URL: http://arbiter.fedorapeople.org/reviews/satsolver/satsolver-0.15.0-2.fc13.src.rpm

Changed package's name.
Also, I added some comments above PatchN and SourceN lines.
Comment 54 Susi Lehtola 2011-08-09 06:06:26 EDT
What's the status of this bug? There is another review at bug #729199.
Comment 55 Susi Lehtola 2011-12-16 04:54:41 EST
Lorenzo - are you still there?
Comment 56 Susi Lehtola 2011-12-16 04:55:20 EST
*** Bug 729199 has been marked as a duplicate of this bug. ***
Comment 57 Lorenzo Villani 2011-12-16 14:21:53 EST
Jussi, I am no longer involved in Fedora for the time being. I relinquished ownership of all my packages about one year ago. I thought I closed or reassigned all of my bugs but, apparently, I was wrong.
Comment 58 Susi Lehtola 2011-12-16 19:21:09 EST
OK, closing.

Note You need to log in before you can comment on or make changes to this bug.