Re: Bug#422137: ITP: 09F911029D74E35BD84156C5635688C0 -- l33t h4x0r numb3r
On 5/4/07, Wesley J. Landaker <firstname.lastname@example.org> wrote:
On Friday 04 May 2007 11:59:20 Roger Leigh wrote:
> Federico Di Gregorio <email@example.com> writes:
> > Il giorno ven, 04/05/2007 alle 10.59 +0200, Stefano Zacchiroli ha
> >> On Fri, May 04, 2007 at 10:32:45AM +0200, Christoph Haas wrote:
> >> > Very good idea. Although the number 09F911029D74E35BD84156C5635688C0
> >> > might look simple it's probably not a good idea to hardcode any
> >> > number like 09F911029D74E35BD84156C5635688C0 into applications.
> >> > Abstracting
> >> So you're proposing to rename the proposed package name to
> >> "lib09F911029D74E35BD84156C5635688C0"?
> > libnumb3rs0? we can bump the soname when the ABI changes, i.e., when an
> > old number is removed from the library or a new one added. :)
> Policy §8.1 would suggest lib09F911029D74E35BD84156C5635688C0-1.
Well, since it would be nice to have a console tool
(i.e. /usr/bin/09F911029D74E35BD84156C5635688C0) to print out this number
for use in shell scripts, as well as having bindings for scripting
languages, I'd like to see this split out into several binary packages at
Surely the architecture-independent content - that is, the value
itself - should be split out into a seperate package, to reduce buildd
And don't forget: