On Tue, Aug 03, 1999 at 11:44:08PM -0700, Joey Hess wrote:
Well we arn't getting anywhere at all with a good transition to
/usr/share/doc, but perhaps this will be easier.
I'm concerned about what happens when packages start using /usr/share/man.
Suppose I convert alien to put it's man pages
Well you're flying in the face of years of tradition if you say that. It's
true it's not written down anywhere, but that doesn't mean you can just
disregard it. Saying that is making a _large_ change to debian's goals.
The only drawback of your proposal are estethical. And it has concrete
Laurent Martelli [EMAIL PROTECTED] writes:
Chris == Chris Waters [EMAIL PROTECTED] writes:
Chris I think this is a great idea in concept. I think
Chris implementation may be a bit tricky, though, and I'd hate to
Chris have to rely on this as a short term solution. But long
Chris
Joey Hess wrote:
Richard Braakman wrote:
Joey Hess wrote:
But when they do, they discover they can no longer read alien's man
page, becuase their old man browser doesn't grok
/usr/share/man. What to do?
They can modify /etc/manpath.config to include /usr/share/man.
So
Le Wed, Aug 04, 1999 at 02:15:38PM -0700, Joey Hess écrivait:
So debian's new statement WRT partial upgrades will be you can install
packages from unstable. However, you may have to edit arbitrary files
and change your system in arbitrary undocumented ways to make them work
as you would
Laurent Martelli [EMAIL PROTECTED] writes:
My very personal opinion about all this, is that we need more
abstraction : packages _should_not_ hardcode installation paths. I
think that it should be an option that the sysadmin should be able to
change anytime, without having to rebuild all
On 5 Aug 1999, Chris Waters wrote:
Laurent Martelli [EMAIL PROTECTED] writes:
My very personal opinion about all this, is that we need more
abstraction : packages _should_not_ hardcode installation paths. I
think that it should be an option that the sysadmin should be able to
change
Chris == Chris Waters [EMAIL PROTECTED] writes:
Chris Laurent Martelli [EMAIL PROTECTED] writes:
My very personal opinion about all this, is that we need more
abstraction : packages _should_not_ hardcode installation
paths. I think that it should be an option that the sysadmin
Well we arn't getting anywhere at all with a good transition to
/usr/share/doc, but perhaps this will be easier.
I'm concerned about what happens when packages start using /usr/share/man.
Suppose I convert alien to put it's man pages there. Alien is arch
independant and there is no reason someone
On Tue, Aug 03, 1999 at 23:44:08 -0700, Joey Hess wrote:
I'm concerned about what happens when packages start using /usr/share/man.
Suppose I convert alien to put it's man pages there. Alien is arch
independant and there is no reason someone using stable can't install the
latest version from
On Aug 03, Joey Hess wrote:
One idea that comes to mind is to make any package that uses /usr/share/man
depend on some package. This might be man-db (= 2.3.10-69g) which is the
first version that support /usr/share/man. Or it might need to be some other
package which itself conflicts with old
First of all, I must say that I did not follow the threads about
/usr/share/doc, so I may say things which were already said. please
forgive me for that.
My very personal opinion about all this, is that we need more
abstraction : packages _should_not_ hardcode installation paths. I
think that it
Well we arn't getting anywhere at all with a good transition to
/usr/share/doc, but perhaps this will be easier.
I'm concerned about what happens when packages start using /usr/share/man.
Suppose I convert alien to put it's man pages there. Alien is arch
independant and there is no reason
J.H.M. Dassen Ray wrote:
Point out that we only support truely smooth upgrades between releases and
that in this case, they need to upgrade their man-db too.
Debian has a history of worrying about incemental upgrades as well.
Otherwise we wouldn't be havcing the whole /usr/share/doc discussion.
Julian Gilbey wrote:
I am extremely wary of adding large amounts of code to support partial
upgrades.
My idea to make it work involves a simgle dependancy. No code.
While we do ensure that the dependenies make the dynamic
linking and suchlike work without a hitch, I do not see it as
Joey Hess wrote:
But when they do, they discover they can no longer read alien's man
page, becuase their old man browser doesn't grok
/usr/share/man. What to do?
They can modify /etc/manpath.config to include /usr/share/man.
Richard Braakman
On Wed, 4 Aug 1999, Joey Hess wrote:
Debian currently has 10 thousand dependancies [1]. I was proposing 1
additional dependancy per package with man page, which does *not* double
that number. 2216 packages contain man pages.
So you want to add a dependency to all of those packages, because
Remco Blaakmeer wrote:
So you want to add a dependency to all of those packages, because some old
package doesn't work with them? Following normal logic, I would say the
would have to have Conflicts: man-db ( the_first_version_that_works),
instead.
I was thinking they could simply depend on
Richard Braakman wrote:
Joey Hess wrote:
But when they do, they discover they can no longer read alien's man
page, becuase their old man browser doesn't grok
/usr/share/man. What to do?
They can modify /etc/manpath.config to include /usr/share/man.
So debian's new statement WRT
19 matches
Mail list logo
