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 #15 from Alec Leamas <leamas.alec(a)gmail.com> 2012-02-19 08:12:38 EST
---
(In reply to comment #14)
(In reply to comment #13)
> (In reply to comment #12)
[cut]
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.
Now, from a
review standpoint, what's the problem? Besides that this is
unusual? The build procedure has certain requirements, and I have solved it
this way. If this is wrong, please explain why.
> > 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_pa...
> 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.
Have you actually packed up and looked into the source? It
might help. Anyway,
maybe we should wait until some of the grown-ups could advice on the possible
problems here.
> > 7. Static libs: see:
> >
https://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libr...
> 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 ?
I'm not bundling boost.
What I do is to build a static library against a
private boost copy in build time. As a last step I relink this against system
boost libraries. The private copy of boost is not installed. So, I don't really
don't know what to ask about.
That I'm not bundling is easily confirmed looking at %files.
> 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.
Basically, I think you
are if you think I'm bundling boost. I'm not.
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).
tools/bjam is built from sources in the
first bootstrap step of the build. It's
not part of the source.
Overall, I probably can't provide much more guidance, someone
with more
experience in these areas would be helpful.
Thanks for your help!
--
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.