Brian May writes:
Ian == Ian Jackson [EMAIL PROTECTED] writes:
Ian However, with the current arrangement I can't do that.
Ian Whenever I want to upgrade a binary package I have to update
Ian the libraries that it depends on to at least as recent a
Ian version. But,
And creates a symlink.
..but not for man pages in /usr/share/man.
a) this seems a pretty minor problem, given people will be able to
read /usr/man/foo and /usr/doc/foo
The man in slink doesn't look at /usr/share/man !
b) Adding two lines of code to debian/rules is so mind-blowingly
easy
On 13-Jan-00, 16:16 (CST), Ian Jackson [EMAIL PROTECTED] wrote:
However, sometimes I'm hit by a killer bug, or want to upgrade a
particular package to the latest and greatest version. Often it's a
while before I can update to the latest stable, and in the meantime a
security fix comes out,
Roland == Roland Rosenfeld [EMAIL PROTECTED] writes:
Roland - If we don't have enough machines available for the above
Roland idea, it would be nice, if someone would create packages
Roland named slink-buildenv, potato-buildenv and so on, which
Roland create a changeroot
Roland Rosenfeld writes (Bug#54985: debian-policy: handling of shared
libraries):
The normal situation is, that users have both packages libfoo and
libfoo-dev up to date, which means, that they are the same version and
then both packages include the identical file.
Perhaps you run only
Matthew Vernon writes (Bug#54985: debian-policy: handling of shared
libraries):
Summary: -dev packages should actually provide a real libfoo.so,
rather than a symlink to the shared object provided by the runtime
package.
Seconded.
Actually, it was me who put Matthew up to this ...
Ian.
debhelper only affects the .deb file, and it should produce correct
.debs regardless of version. mybe some compilers etc. seems like
FUD to me.
Wrong. Take as example that the potato debhelper installs docs into
/usr/share/doc, and the stable one to /usr/doc. Same for man pages...
OK, so
-policy: handling of shared
libraries):
The normal situation is, that users have both packages libfoo and
libfoo-dev up to date, which means, that they are the same version and
then both packages include the identical file.
Perhaps you run only systems which are up to date with unstable
Roman Hodek writes:
debhelper only affects the .deb file, and it should produce correct
.debs regardless of version. mybe some compilers etc. seems like
FUD to me.
Wrong. Take as example that the potato debhelper installs docs into
/usr/share/doc, and the stable one to /usr/doc.
On Fri, Jan 14, 2000 at 12:07:53PM +, Matthew Vernon wrote:
Roman Hodek writes:
debhelper only affects the .deb file, and it should produce correct
.debs regardless of version. mybe some compilers etc. seems like
FUD to me.
Wrong. Take as example that the potato
Package: debian-policy
Version: 3.1.1.1
Severity: normal
Hi all,
Summary: -dev packages should actually provide a real libfoo.so,
rather than a symlink to the shared object provided by the runtime
package.
The object of this proposal is to divorce the version of the -dev
package from the
On Thu, 13 Jan 2000, Matthew Vernon wrote:
Summary: -dev packages should actually provide a real libfoo.so,
rather than a symlink to the shared object provided by the runtime
package.
Which means, that everybody, who installs a -dev package, has two
identical files on his machine. I don't
Roland Rosenfeld writes:
On Thu, 13 Jan 2000, Matthew Vernon wrote:
Summary: -dev packages should actually provide a real libfoo.so,
rather than a symlink to the shared object provided by the runtime
package.
Which means, that everybody, who installs a -dev package, has two
On Thu, 13 Jan 2000, Matthew Vernon wrote:
Which means, that everybody, who installs a -dev package, has two
identical files on his machine. I don't like this implication,
it's
Not necessarily - they certainly may be identical, but not
necessarily.
The normal situation is, that
14 matches
Mail list logo