On Sat, 04 Aug 2007, Loïc Minier wrote:
> On Sat, Aug 04, 2007, Raphael Hertzog wrote:
> > Knowing those differences, I wonder if I should offer the possibility to
> > have
> > debian/<package>.symbols.common that would complement what can be found in
> > debian/<package>.symbols.<arch> or if we need something more elaborated like
> > an include mechanism or a syntax to restrict a symbol on a set of
> > architectures
> > (like for dependencies in Build-Depends). Please give me your opinion on
> > this.
>
> I wish for an include mechanism! :)
It probably makes sense however it's not always easy to define a
correct semantic:
Let's consider debian/symbols.i386:
| #include <symbols.all-archs>
| libc.so.6 libc6 #MINVER#
| symbol1 2.6-1
And debian/symbols.all-archs:
| libc.so.6 libc6 #MINVER#
| symbolX 2.6-1
| symbolY 2.6-1
[...]
1/ What should happen if the dependency template ("libc6 #MINVER#") is not
the same in both files? If one gets precedence over the other, which one?
2/ What should happen when a symbol is defined in both files? (Two cases:
the version differs or they are the same)
3/ Do we have to create a syntax to "remove" a symbol as part of an
include file ?
My first preference would be to detect all those cases (1/ and 2/) and fail.
You should also note that the build log provides a "diff" of the symbols
file in case there are inconsistencies, but the diff is not directly
applicable if you use an include mechanism. Duplication is bad, but it may
be easier to manage.
> I think this also makes sense when you have multiple flavors of the
> same lib (for example libgtk versus libgtk-directfb).
Right. Or curl. :)
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
