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 p
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/
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. B
> 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
b
> "JP" == Jean Pierre LeJacq <[EMAIL PROTECTED]> writes:
JP> 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
>>
> "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 th
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
>
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
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 ex
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 W
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 depe
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
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
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
> rea
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 discussio
> 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 rea
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 s
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 wit
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 fro
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
20 matches
Mail list logo
