1:48 a.m.
Hi,
I'm packaging a library, but the problem is that this package will
generate a binary of its implementation.
I think libxxx packages should only contain .so.*/.h files, and I
cannot put it into devel package, so can I put it into main package? I
don't want to create a subpackage for this file.
Thanks.
Yours sincerely,
Christopher Meng
Always playing in Fedora Project
http://cicku.me
9:51 a.m.
On Sat, Jul 20, 2013 at 2:48 AM, Christopher Meng <cickumqt(a)gmail.com> wrote:
Hi,
I'm packaging a library, but the problem is that this package will
generate a binary of its implementation.
I think libxxx packages should only contain .so.*/.h files, and I
cannot put it into devel package, so can I put it into main package? I
don't want to create a subpackage for this file.
Thanks.
Is there some reason it shouldn't be:
package (with the binary)
libpackage (with the library)
And, if necessary for managing components of the library, put in:
Requires: package
in the libary part of the .spec file? And what requires the binary
after the library is installed.
In other words, what is the package?
10:17 a.m.
Christopher Meng wrote:
I'm packaging a library, but the problem is that this package
will
generate a binary of its implementation.
I think libxxx packages should only contain .so.*/.h files
IMO, splitting such items into a subpkg 100% of the time is not practical.
It generally only makes sense if:
* size is significant
* helps avoid multilib conflicts
* insert some other good reason I can't think of
Do you have some other good reason? :)
-- rex
10:27 a.m.
On Sat, Jul 20, 2013 at 10:17:50AM -0500, Rex Dieter wrote:
Christopher Meng wrote:
> I'm packaging a library, but the problem is that this package will
> generate a binary of its implementation.
> I think libxxx packages should only contain .so.*/.h files
IMO, splitting such items into a subpkg 100% of the time is not practical.
It generally only makes sense if:
* size is significant
* helps avoid multilib conflicts
* insert some other good reason I can't think of
I think the final reason is: "the tool implementing the library is actually
the most important/useful consumer".
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
6:19 p.m.
No, in fact the library is the most important part. This library is libxls,
a very nice library to handle Excel files.
The problem is that the binary is named
xls2csv, which is already taken in the repo by another perl program. And
xls is not good to name it.
So I cannot either add a new subpackage named xls2csv or use xls to require
the libxls. That's why I have no idea...
Thanks everyone!
Sent from S3
3:23 a.m.
Hi Christopher,
On Sunday, 21 July 2013 at 01:19, Christopher Meng wrote:
No, in fact the library is the most important part. This library is
libxls,
a very nice library to handle Excel files.
IMHO you can package the binary as libxls-tools or -utils.
The problem is that the binary is named
xls2csv, which is already taken in the repo by another perl program. And
xls is not good to name it.
In this case you should coordinate with the maintainer of the package
that provides that perl program and one of you should rename your
binary. Asking upstreams first is advised, too.
Regards,
Dominik
--
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
3932
days inactive
3934
days old
packaging@lists.fedoraproject.org
6 comments
5 participants
participants (5)
-
Christopher Meng -
Dominik 'Rathann' Mierzejewski -
Matthew Miller -
Nico Kadel-Garcia -
Rex Dieter