FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 07-08-2011, 03:06 PM
Richard Shaw
 
Default Development only package?

I'm working on making a package of OpenImageIO[1] which is used by a
new branch of blender, blender-cycles[2], which uses the cycles
rendering engine[3].

There appears to be one bundled library, pugixml[4] but it's only 3
files (1 c, and 2 header files) and doesn't not compile on it's own.
It looks to be designed intentionally to be built in to other
programs.

Should I package it as "pugixml-devel" only? Or just "pugixml"?

Thanks,
Richard

[1] https://sites.google.com/site/openimageio/home
[2] http://wiki.blender.org/index.php/Dev:2.5/Source/Render/Cycles/Building
[3] http://www.youtube.com/watch?v=8KgrBjt4e9k (video demo)
[4] http://pugixml.org/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 04:48 PM
Toshio Kuratomi
 
Default Development only package?

On Fri, Jul 08, 2011 at 10:06:56AM -0500, Richard Shaw wrote:
> I'm working on making a package of OpenImageIO[1] which is used by a
> new branch of blender, blender-cycles[2], which uses the cycles
> rendering engine[3].
>
> There appears to be one bundled library, pugixml[4] but it's only 3
> files (1 c, and 2 header files) and doesn't not compile on it's own.
> It looks to be designed intentionally to be built in to other
> programs.
>
The tarball (I actually downloaded the zip but I hope that upstream made the
tarball contain identical files :-) seems to compile fine on its own:

cd scripts
cmake CMakeLists.txt
make
ls -al libpugixml.a
-rw-rw-r--. 1 badger badger 342992 Jul 8 09:42 libpugixml.a

> Should I package it as "pugixml-devel" only? Or just "pugixml"?
>
Since only static libraries are created you should be able to use these
guidelines:
http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 05:41 PM
Richard Shaw
 
Default Development only package?

On Fri, Jul 8, 2011 at 11:48 AM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> The tarball (I actually downloaded the zip but I hope that upstream made the
> tarball contain identical files :-) *seems to compile fine on its own:
>
> cd scripts
> cmake CMakeLists.txt
> make
> ls -al libpugixml.a
> -rw-rw-r--. 1 badger badger 342992 Jul *8 09:42 libpugixml.a

Thanks, I don't know why I didn't look there, I guess I was looking
for some sort of makefile in the root of the archive.


>> Should I package it as "pugixml-devel" only? Or just "pugixml"?
>>
> Since only static libraries are created you should be able to use these
> guidelines:
> http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries

I'll take a look. Thanks!

Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 05:46 PM
Richard Shaw
 
Default Development only package?

Ok, another question. I edited the CMakeLists.txt and changed the
"STATIC" to "SHARED" and it compiled without issue creating a shared
library. Is there any down side to doing this?

I guess now I have something for the pugixml package and then can
create a -devel subpackage with the header file and API documentation.

Thanks,
Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 05:50 PM
Orcan Ogetbil
 
Default Development only package?

On Fri, Jul 8, 2011 at 12:48 PM, Toshio Kuratomi wrote:
> On Fri, Jul 08, 2011 at 10:06:56AM -0500, Richard Shaw wrote:
>> I'm working on making a package of OpenImageIO[1] which is used by a
>> new branch of blender, blender-cycles[2], which uses the cycles
>> rendering engine[3].
>>
>> There appears to be one bundled library, pugixml[4] but it's only 3
>> files (1 c, and 2 header files) and doesn't not compile on it's own.
>> It looks to be designed intentionally to be built in to other
>> programs.
>>
> The tarball (I actually downloaded the zip but I hope that upstream made the
> tarball contain identical files :-) *seems to compile fine on its own:
>
> cd scripts
> cmake CMakeLists.txt
> make
> ls -al libpugixml.a
> -rw-rw-r--. 1 badger badger 342992 Jul *8 09:42 libpugixml.a
>

What about the case where the upstream tarball is not directly capable
of generating a dynamic or static library?

This is the situation for a review that I am doing [1]. vmpk bundles
the rtmidi [2], but rtmidi is not available as an independent library.
It consists of 1 source and 2 header files and is designed to be
bundled in other software. Is it okay to bundle rtmidi in our vmpk
package?

Thanks,
Orcan

[1] https://bugzilla.redhat.com/show_bug.cgi?id=710917
[2] http://www.music.mcgill.ca/~gary/rtmidi/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 07:50 PM
Toshio Kuratomi
 
Default Development only package?

On Fri, Jul 08, 2011 at 12:46:37PM -0500, Richard Shaw wrote:
> Ok, another question. I edited the CMakeLists.txt and changed the
> "STATIC" to "SHARED" and it compiled without issue creating a shared
> library. Is there any down side to doing this?
>
> I guess now I have something for the pugixml package and then can
> create a -devel subpackage with the header file and API documentation.
>
The downside is that the dynamic linker has a limited understanding of
versioning so that libfoo.so.2 and libfoo.so.3 are considered incompatible
but libfoo.so.2.0 and libfoo.so.2.1 are compatible. If upstream is making
releases of its libraries without thinking about compatibility and
versioning you may lead people to make false assumptions about this. The
best bet here is to talk to the pugixml upstream, letting them know how easy
it is to build shared libraries and asking if they're interested in managing
their versions appropriately for that use case.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 07:52 PM
Richard Shaw
 
Default Development only package?

On Fri, Jul 8, 2011 at 2:50 PM, Toshio Kuratomi <a.badger@gmail.com> wrote:
> On Fri, Jul 08, 2011 at 12:46:37PM -0500, Richard Shaw wrote:
>> Ok, another question. I edited the CMakeLists.txt and changed the
>> "STATIC" to "SHARED" and it compiled without issue creating a shared
>> library. Is there any down side to doing this?
>>
>> I guess now I have something for the pugixml package and then can
>> create a -devel subpackage with the header file and API documentation.
>>
> The downside is that the dynamic linker has a limited understanding of
> versioning so that libfoo.so.2 and libfoo.so.3 are considered incompatible
> but libfoo.so.2.0 and libfoo.so.2.1 are compatible. *If upstream is making
> releases of its libraries without thinking about compatibility and
> versioning you may lead people to make false assumptions about this. *The
> best bet here is to talk to the pugixml upstream, letting them know how easy
> it is to build shared libraries and asking if they're interested in managing
> their versions appropriately for that use case.

Well I went ahead and created a shared library package with soname,
for now it's the same as the version. I submitted the patch upstream
so we'll see what they think.

Thanks for the help!

Richard
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-08-2011, 08:04 PM
Toshio Kuratomi
 
Default Development only package?

On Fri, Jul 08, 2011 at 01:50:34PM -0400, Orcan Ogetbil wrote:
>
> What about the case where the upstream tarball is not directly capable
> of generating a dynamic or static library?
>
This would not be a guarantee that it is okay to bundle the library. It
would be one indicator but not the most important one.

> This is the situation for a review that I am doing [1]. vmpk bundles
> the rtmidi [2], but rtmidi is not available as an independent library.
> It consists of 1 source and 2 header files and is designed to be
> bundled in other software. Is it okay to bundle rtmidi in our vmpk
> package?
>
You're definitely getting into a grey area here and may well want to submit
this case to the FPC for an exception. Process and standard questions to
answer here:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions

In general, if the library is being distributed as a separate upstream, you
can err on the side of making it available as a library and the packaging
guidelines will be happy but to bundle it you'll have to show that there's
a good reason for that. The idea is that as the "library" upstream releases
new code the apps need to be kept up-to-date with that new code. Sometimes
this is because the library is making security fixes which means that we
have to update. Sometimes it's because some API is changing incompatibly
and the library upstream is not going to put any maintainance effort into
the old API. The latter can tempt upstream apps to bundle the library. But
unless they simultaneously commit to maintaining their fork of the code in
case of the former problems, we end up being on the hook to audit and
produce security fixes for the bundled libraries at a later date.

If the software is designed to be bundled into other software and modified
by those consuming the code (with appropriate records of that on upstream
websites, etc) then the FPC may grant an exception but we will have an
easier time granting an exception if it can be shown that the application
doing the bundling recognizes that they're assuming the burden of fixing the
bundled library, are capable of making security fixes to the bundled
library and understand the gravity of what they're doing. In many cases,
upstreams only look at the short term cost savings of being able to take
someone else's implementation of something into their code base without
thinking about the long term cost of maintaining that foreign code into the
future.

-Toshio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-15-2011, 04:56 PM
Kevin Kofler
 
Default Development only package?

Toshio Kuratomi wrote:
> cmake CMakeLists.txt

FYI, that's the default file name, so:
cmake .
is sufficient. (You do have to give it a parameter, but the dot for the
current directory is sufficient.)

Also note that it's in general cleaner to build in a separate directory
(passing a relative path to CMakeLists.txt, but there too, this need not
include the "CMakeLists.txt" file name itself), not in the directory
containing CMakeLists.txt.

Kevin Kofler

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 10:22 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org