Posted: Sun 10 Feb 2013, 08:00
Thanks to technosaurus -for keeping some poor folks hope alive that there is a way around doing things sanely. Of course, you know much more about these things than I do and are a master at building things statically. I know there are ways around some of these problems, but as you know, they are not simple. My desire is that people here become convinced of the usefulness of sane building tactics -and especially that what seems to be the 'hard way' is really the easy way. The tricks you mention are way beyond the scope of any development cycle. for instance, how long did it take to get scite to do what you wanted? Could you do that for 237 other programs and still keep up with upgrading them when necessary? And, in between, you (as a developer) might want to write some new stuff -setup routines and other distro-specific stuff... Anything is possible, but some schemes are simply not practical for real scenarios. Also, you are talking about uclibc, which doesn't suffer from the well know 'a-hole problem' that glibc does.... One of the many reasons you prefer uclibc over glibc.
@tallboy, yes there is a way to 'sign' packages which makes the name unique to a certain system. It must consist of a unique name, the lib/prog version, the architecture, the build number and optionally a signature -which can indicate who built the package or for what distro variant it was built, something like this:
myproggie-0.1-i586-1_billybob
where the '-1' is the build number and billybob is the signature. Of course the sig could indicate the person and variant. Anyway, you can probably understand all that except the 'build' number. build numbers are used to distinguish new builds where the program version is not changed. when I first build myproggie-0.1, then the whole string looks as above: myproggie-0.1-i586-1_billybob
But, if I make a mistake, or decide to include somethigng else in the package, then the next build would be: myproggie-0.1-i586-2_billybob, and so on.
Still, there is lots more info which should be available some way, like the date of the build, exact details about the toolchain, etc. The only way to do so is with database files -preferably included inside the package. A central database with the info is simply unmaintainable. On my KISS system, each package contains an overkill of info about itself -even down to the md5sum of every file included. if anyone ever wants to find out if any files on their system have been modified, then the database provides all the necessary info. Of course, each package also contains a list of the exact versions of any libs/progs it depends on. The complete database allows for lots of usage scenarios. For instance, I can query it to tell me which programs a package depends on *and the order in which those dependencies must be built*. Or I can find libs which no programs depend on... There's no substitute for information.
@tallboy, yes there is a way to 'sign' packages which makes the name unique to a certain system. It must consist of a unique name, the lib/prog version, the architecture, the build number and optionally a signature -which can indicate who built the package or for what distro variant it was built, something like this:
myproggie-0.1-i586-1_billybob
where the '-1' is the build number and billybob is the signature. Of course the sig could indicate the person and variant. Anyway, you can probably understand all that except the 'build' number. build numbers are used to distinguish new builds where the program version is not changed. when I first build myproggie-0.1, then the whole string looks as above: myproggie-0.1-i586-1_billybob
But, if I make a mistake, or decide to include somethigng else in the package, then the next build would be: myproggie-0.1-i586-2_billybob, and so on.
Still, there is lots more info which should be available some way, like the date of the build, exact details about the toolchain, etc. The only way to do so is with database files -preferably included inside the package. A central database with the info is simply unmaintainable. On my KISS system, each package contains an overkill of info about itself -even down to the md5sum of every file included. if anyone ever wants to find out if any files on their system have been modified, then the database provides all the necessary info. Of course, each package also contains a list of the exact versions of any libs/progs it depends on. The complete database allows for lots of usage scenarios. For instance, I can query it to tell me which programs a package depends on *and the order in which those dependencies must be built*. Or I can find libs which no programs depend on... There's no substitute for information.