[Bug 790628] Review Request: Adobe Source Libraries - General Purpose Addon for Boost and STL

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=790628

--- Comment #14 from David Timms <dtimms at iinet.net.au> 2012-02-19 07:39:36 EST ---
(In reply to comment #13)
> (In reply to comment #12)
> > 1. The source download pointed to by the web page is a sf download. You would
> > usually use a full URL for the Source0. Fedora uses a specific fixed URL to
> > access sf sources, see:
> > https://fedoraproject.org/wiki/Packaging:SourceURL#Sourceforge.net
> The source is actually  a combo of ASL and boost + a link, packed together in
> the way ASL needs to be built. I've put a short-form of this info in the
> comment. While this could be done it the %prep stage, I have concluded that it
> becomes just a to messy (yes, I have tried :) )

Usually we package either a major version, or some post or pre release version
from some sort of code repository. I can't tell which this is.

> > Unless you are packaging direct from version control, and if so, should state
> > why, and the Release: would need work to fit with one of Fedora's pre/post
> > release naming schemes, see:
> > https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Post-Release_packages
> What's wrong with "Release:  3%{?dist}" ?
If you are using the upstream zip/archive then it's fine, and just include the
sf.net download using the method in the guidelines.

If this is a source checkout from some code repository, the guidelines show how
to specify that type of checkout (eg date, cvs/svn/git version/checksum). This
comes from rpm being a build from source system, where anyone should be able
build the identical binary based on the information in the spec. Hence we would
need to know the upstream checkout version to start with... There are possibly
some exceptions to this.

> > 7. Static libs: see:
> > https://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libraries
> Is this applicable?! I'm not packaging a static library, I'm building a static
> library which is converted to a dynamic in the following steps. Or am I
> missing something?

You might have to query someone ith more knowledge in this area, but it seems
that you are bundling a different version of boost, and then linking to that,
rather than to the distribution's boost version ?

> Once again, solved what?!
Fedora packages avoid bundling libraries that are already in the distro, and so
you would need to get specific permission/allowance to bundle it. I might be
totally off base - perhaps another opinion would be good.

> > 8. tools/bjam: is this tool already in fedora ? If so, then BuildRequire it
> > instead.
> Yes, it's there, but not compatible, I have actually tried. Since this is not
> installed, just used in the build process I don't see the problem here either.

The build process would also normally be required to be built either from
packages already in Fedora, or from source, although a few packages have
explicit exceptions (eg java from memory).

Overall, I probably can't provide much more guidance, someone with more
experience in these areas would be helpful.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.