On Mon, 30 Apr 2012 11:07:51 +0200, RC (Ralf) wrote:
> >> At first thought, I was inclined to agree, but ...
> >>
> >> ... where do you want to draw the line between "static template usage"
> >> and "regular external code usage"?
> >
> > This is too vague for me to comment on. Have you read my comment in the
> > bugzilla ticket? I might answer your question as it also points out what
> > you write below.
>
> I don't understand what you want to hear.
My initial post contains a single question only:
What does the Packaging Committee think about the following?
I think that header-only library packages (where the ambiguous term
"library" could be substituted with "archive", "framework", "toolkit"
e.g.) should fall under the static library packaging guidelines. For the
same reasons those guidelines exist.
Trying to cover arbitrary header files in arbitrary packages would be
something different. Obviously, one needs to be very careful with regard
to publishing updates that touch the API.
> There are packages which, at build time include headers from other
> packages and use inlined-only code, defines-only code from these
> headers, without actually pulling-in run-time dependencies on
> corresponding libraries (the lib*.so, etc.).
Which I've commented on [briefly] in the bz ticket. Specifically, I called
it a "grey area". I can imagine scenarios such as compiling a program with
constant values defined in API headers, which change during an update and
affect the program's run-time behaviour. But I don't seek for the holy grail.
Hence a topic on header-only -devel packages.
> I.e. these packages inherit the bugs/changes these inlines/defines-only
> code fragments may contain and nobody will notice.
The same applies to static libs. Those are just _more_ special, because
fixes in a static lib haven't got any chance at all to affect statically
linked programs. This is what they have in common with header-only -devel
packages.
> Now, adding explict tags for "inlines/defines-only" devel-packages only
> covers a very small subset of such cases. The mixed cases are much more
> common.
Sure, but if all that matters is quantity, we could get rid of the static
lib guidelines, too. ;)
http://mschwendt.fedorapeople.org/staticbugstat.html hasn't become
too long yet, but it could be that maintainers aren't notified properly
about updates to static libs.
Who cares if static lib packages follow the guidelines, if statically
linked apps get rebuilt _from time to time_ anyway? Hey, let's forget
about tracking static lib usage. Who cares about security-fixes in
static libs? Just kidding!
> In this context, my "where to draw the line" question was aiming at
> "when do you want a package to be treated specially?".
Okay, the answer to that is:
When changes in the packaged files are unable (!) to affect run-time
behaviour of existing dependencies.
> To exaggerate: Is adding a stub library to a "header only" package
> enough to exclude if from special treatment?
That's not the case I've asked about, and your personal goal of trying "to
draw a line" complicates matters in my opinion.
On the contrary, one goal of packaging guidelines is to give packagers a
hint on what to keep in mind when creating a package and during its
life-time.
> To cover "mixed cases", one would have to track each and every single
> define, inline and even types in all headers, everywhere, because
> changes to them can introduce run-time incompatibilities.
>
> Imagine a library to change one of its public types from int to short or
> moving around some #defines in one of its headers, The result would be
> silent and often unnotices havoc at run-time.
There are work-in-progress API/ABI checkers to help packagers, so
skimming over diffs is no the only thing that can be done.
> > Of course! There are C header-only libraries, too.
> I am not talking about "whole libraries". I am talking about individual
> files.
Well, I've asked about a header-only (library-less) -devel package.
Just a request for comments.
> AFAU, we don't handle this case at all, but trust in upstreams doing a
> reasonable job and in packagers doing so as well.
Which may have been an early answer to my initial question. ;-)
It could also be that handling header-only packages and static libs
could find a mention on the Package Maintainer Responsibilities page:
https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Notify_others_of_changes_that_may_affect_their_packages
--
Fedora release 17 (Beefy Miracle) - Linux 3.3.4-1.fc17.x86_64
loadavg: 0.00 0.01 0.05
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
