| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Thursday 05 February 2004 12:20, Marius Mauch wrote: |
| 5 |
> X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i686-pc-linux-gnu) |
| 6 |
> Mime-Version: 1.0 |
| 7 |
> Content-Type: text/plain; charset=US-ASCII |
| 8 |
> Content-Transfer-Encoding: 7bit |
| 9 |
> |
| 10 |
> On Thu, 5 Feb 2004 11:20:42 +0100 |
| 11 |
> |
| 12 |
> Spider <spider@g.o> wrote: |
| 13 |
> > So my question was for the generic case of things like this, Can |
| 14 |
> > the binaries be made more reliable? |
| 15 |
> > |
| 16 |
> > Perhaps this sort of thing be worked around in portage-code? ( wrap |
| 17 |
> > a consistency check of linking before installing? demand that a |
| 18 |
> > system is"updated" ? ) |
| 19 |
> > |
| 20 |
> > Or should binaries have more metadata in them, perhaps a specific |
| 21 |
> > requirement for libraries? (sheesh, then its down to RPM again. |
| 22 |
> > that's bad. ) |
| 23 |
> |
| 24 |
> Why more metadata? Can't we just run a ldd check on the binaries, |
| 25 |
> check that the relevant libraries are present, if not do a lookup in a |
| 26 |
> (to-be-created) list of library<->package mappings and add the |
| 27 |
> relevant packages as PDEPEND? (or yell at the user to provide that |
| 28 |
> library ;) |
| 29 |
|
| 30 |
Partly because first of all whe then would unpack those libs and do some |
| 31 |
magic to take local libs into account. Further the mappings is exactly |
| 32 |
the thing that redhat does that we cannot do easilly (which we probably |
| 33 |
don't want either). |
| 34 |
|
| 35 |
Paul |
| 36 |
|
| 37 |
- -- |
| 38 |
Paul de Vrieze |
| 39 |
Gentoo Developer |
| 40 |
Mail: pauldv@g.o |
| 41 |
Homepage: http://www.devrieze.net |
| 42 |
-----BEGIN PGP SIGNATURE----- |
| 43 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 44 |
|
| 45 |
iD8DBQFAIiijbKx5DBjWFdsRAv7/AKCyu7NaqkCbJijnFyEGANtqLPQCFQCfZ8DZ |
| 46 |
s8PeQUx1nOkCU++R57bCyUE= |
| 47 |
=3la3 |
| 48 |
-----END PGP SIGNATURE----- |
| 49 |
|
| 50 |
-- |
| 51 |
gentoo-dev@g.o mailing list |
Archives