On Sat, 19 Jan 2008, Mark Brown wrote: > On Sat, Jan 19, 2008 at 02:12:50PM +0100, Raphael Hertzog wrote: > > > I'm sorry I don't understand. Why should they not be there and why can't > > they be hidden/removed if they are not wanted? > > They shouldn't be there because they are there to provide access to a 64 > bit off_t on 32 bit architectures. When off_t is already 64 bit they > are redundant. I could hide or remove them but I prefer to be extremely > conservative in introducing any deviation from upstream behaviour so I'd > rather have that change made upstream.
Ok, that's what I expected. I agree it's something to discuss with upstream. > > Also if nobody is suppossed to link against them, and if you can't make > > them disappear, what about associating them to an unsatisfiable > > dependency for examples with entries like: > > I had assumed that you would complain about doing that too. Well I wouldn't, but maybe users of the *64 symbols would... in the end I think that either we support the *64 symbols like the others (since upstream does), or we decide that they shouldn't be used and we make it explicit with such a change. BTW, I noticed two other potential problems: [EMAIL PROTECTED] 1:1.1.2 [EMAIL PROTECTED] 1:1.1.4 Why do the minimal version not match the version of the symbol ? > Oh, bah humbug. I see - I hadn't realised that any attention was being > paid to the package name in the header there. I had been under the > impression for some reason that the package name for the dependency was > generated from the package containing the symbol file. I remember > looking at the header line, scratching my head about what the MINVER > stuff was about and making a note to look at it when I worked out what > it did but that never happened. > > I'll do yet another upload today or tomorrow. Thanks. > I have to say I find the specification of the package name in this way > somewhat uncomfortable - with the 32/64 bit zlib varaints the toolchain > must already have worked out which package contains the relevant libary > in order to identify the relevant symbols flle. I'd be more comfortable > if I were You forgot to finish the sentence... :-) but anyway, it's not really possible because one might want to generate a more complicated dependency like "helper-tools, virtuallib | reallib #MINVER#". So the dependency that is generated is really free-form and you can embed somewhere a #MINVER# that will be replaced by the calculated "(>= minver)". (In the shlibs one can also put whatever he wants except that the shlibs is auto-generated most of the time while the symbols file needs more handholding) But maybe we can have a lintian warning if the name of the package appears nowhere in the dependency. > Sure, it wasn't that I felt this was an attack. It was more that I had > found the existing behaviour of the tools very useful (I especially like > the fact that it will keep triggering warnings in the build) but that > using this ended up generating high severity bug reports. Well, I put important because I thought you overlooked it not because the problem was really critical. And while I agree the warnings are useful, I don't understand why one would want to keep them instead of taking proper measures to not generate them. :) > > We're still discovering what good practices are and that's why I submitted > > this bug and that's why I added the lintian check. I didn't expect that it > > was a deliberate choice of yours to not list symbols which are actually > > provided by the lib. > > The way I was looking at it the symbol files are a declaritive thing > saying which symbols should be in the library and which minimum versions > apply to each (this is why I don't autogenerate the lists of 64 and 32 > bit cross architectures). That's the general logic yes. Though if other symbols are provided and shouldn't be used, I'd rather make that explicit than let them generate a dependency on a recent version of the lib which might go unnoticed. Maybe we need some standard mechanism for this, I don't know. Initially I drafted that we could put "-" as version on some symbols to mean that they are private and shouldn't be used but I never implemented that. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
