On Mon, Sep 20, 1999 at 03:59:13PM +0300, Antti-Juhani Kaijanaho wrote:
> On Sun, Sep 19, 1999 at 11:03:05PM -0400, Raul Miller wrote:
> > I've seen some people claim that the FHS transition issue has been
> > handled, but we still don't have a policy for it.
>
> Didn't the Technical Committee cho
On Sun, Sep 19, 1999 at 11:03:05PM -0400, Raul Miller wrote:
> I've seen some people claim that the FHS transition issue has been
> handled, but we still don't have a policy for it.
Didn't the Technical Committee choose one some time ago?
--
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http:
[EMAIL PROTECTED] (Charles Briscoe-Smith) wrote on 05.11.98 in <[EMAIL
PROTECTED]>:
> Ian Jackson wrote:
> >You must be kidding.
[...]
> My main problems with your proposal are:
[...]
> 3) It involves deliberately invalidating dpkg's database. It's fine
> that dpkg is capable of follow
I wrote:
>> A better way of handling this transition might be dpkg-divert.
>> (I'm not _au fait_ with dpkg-divert's details, so I'm not sure how
>> much it would need to be improved before it could be used like this.)
>> Assuming dpkg-divert is (modified to be) capable of diverting whole
>> directo
Quoting Ian Jackson ([EMAIL PROTECTED]):
> Michael Stone writes ("Re: FHS - transition"):
> > Hmm. Try installing sendmail from slink on a hamm system. And no one
> > seems to be addressing that either. Or try dropping the latest apt into
> > hamm.
>
> Shoul
Michael Stone writes ("Re: FHS - transition"):
...
> Hmm. Try installing sendmail from slink on a hamm system. And no one
> seems to be addressing that either. Or try dropping the latest apt into
> hamm.
Should these things perhaps be reported as bugs ?
Ian.
Michael Stone <[EMAIL PROTECTED]> wrote:
> Hmm. Try installing sendmail from slink on a hamm system. And no one
> seems to be addressing that either. Or try dropping the latest apt into
> hamm. I'm starting to doubt that any debian release will be 'partially
> upgradeable,' but that's probably not
Quoting Ian Jackson ([EMAIL PROTECTED]):
> This is explicitly NOT WHAT WE HAVE PROMISED OUR USERS.
>
> For years, we have promised them INCREMENTAL UPGRADEABILITY. We broke
> that promise in 2.0, and I hope we never break it again.
>
> It is IMO _essential_ that a user can take a single package o
Charles Briscoe-Smith writes ("Re: FHS - transition"):
> Ian Jackson wrote:
...
> > * will require upgrade of many packages for forward compatibility.
>
> How many browsers are in use on each machine? How many machines are
> upgraded one package at a time? (I su
Manoj Srivastava writes ("Re: FHS - transition"):
> Ian Jackson <[EMAIL PROTECTED]> writes:
> > To my mind, a flag day is a point in time when the entire universe
> > must change simultaneously, or at least across which mechanisms do not
> > interoperate. I fe
Hamish Moffatt writes ("Re: FHS - transition"):
> On Thu, Oct 22, 1998 at 07:40:15PM -0300, Nicolás Lichtmaier wrote:
> > The main point are: `Do things in a way that old programs would still
> > work.' You can't know what weird setup a user is trying to u
On Thu, Oct 22, 1998 at 07:40:15PM -0300, Nicolás Lichtmaier wrote:
>
> The main point are: `Do things in a way that old programs would still
> work.' You can't know what weird setup a user is trying to use, perhaps he
> has a custom CGI script to read manpages, one no debian-developer knows of.
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> To my mind, a flag day is a point in time when the entire universe
Ian> must change simultaneously, or at least across which mechanisms do not
Ian> interoperate. I feel that a flag day necessarily occurs at the same
Ian> time for eve
Ian Jackson wrote:
> To my mind, a flag day is a point in time when the entire universe
> must change simultaneously, or at least across which mechanisms do not
> interoperate. I feel that a flag day necessarily occurs at the same
> time for everyone.
>
> In my proposal, there is no such day. Ev
On Thu, Oct 22, 1998 at 07:40:15PM -0300, Nicolás Lichtmaier wrote:
> All migarions I have `survived' in Linux used a similar approach:
>
> The `cua0 -> ttyS?' change wasn't carried out by:
> 1) patching every program to fallback to ttyS?.
> 2) removing cua? support from the kernel.
> Ian> Please explain to me what part of my proposal contained an embarassing
> Ian> kludge ?
> A symlink to be removed on a flag day, things mass copied
> over, and another symlink placed, is not a kludge?
All migarions I have `survived' in Linux used a similar approach:
The `cua0 ->
Manoj Srivastava writes ("Re: FHS - transition") [1]:
> "Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
> > My scheme:
...
> > * [list of bullet points snipped]
>* Needs a flag day for the transition
To my mind, a flag day is a point
ntually have to be cleaned up with
> scripts anyway.
Why is it a mess to have files in two places? Why does this matter?
I don't think there will be any need to use scripts to clean up; when
all packages use /usr/share/{man,info}, /usr/{man,info} should be empty.
When base-files no lo
On 17 Oct 1998, Adam P. Harris wrote:
> Santiago Vila <[EMAIL PROTECTED]> writes:
> [...]
> > They are not just "things that would be nice to have implemented"
> > (wishlist). We really *need* to have them fixed in the near future.
> > Otherwise we will never move to FHS.
>
> Woah there, one step
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> Biased summary:
Biased is right.
Ian> My scheme:
Ian> * keep the user's filesystem consistently laid out during transition.
Ian> * allows the transition to be controlled explicitly by a single script.
Ian> * allows us to
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> Manoj Srivastava writes ("Re: FHS - transition"):
Ian> ...
>> I would much rather have a slow
>> transition with information browsers able to handle the transition
>> seamles
Manoj Srivastava writes ("Re: FHS - transition"):
...
>I would much rather have a slow
> transition with information browsers able to handle the transition
> seamlessly to being confronted with the choice of a flag day or an
> embarrassing klud
tc.) which will eventually have to be cleaned up with
scripts anyway.
Santiago Vila writes ("Re: FHS - transition"):
...
> Better having to upgrade the manpage program than upgrading base-files,
> which has nothing to do with manpages.
In some sense, perhaps. However: base-
At 22:06 +0200 1998-10-15, Santiago Vila wrote:
On 10 Oct 1998, Adam P. Harris wrote:
2. info browsers, manual pagers, terminfo libraries, etc., are
Yes, but where is the info program that looks in both directories?
In the 'info' package. Start info and hit C-h, and in the help is:
The cur
Santiago Vila <[EMAIL PROTECTED]> writes:
> On 16 Oct 1998, Adam P. Harris wrote:
> > I think, say, filiing important bugs on the relevant packages would
> > suffice to ensure that the issue is fixed prior to the release.
> > Clearly I'm not proposing to do this now -- no, only once we've
> > resol
On 16 Oct 1998, Adam P. Harris wrote:
> Santiago Vila <[EMAIL PROTECTED]> writes:
> > On 10 Oct 1998, Adam P. Harris wrote:
> > > 2. info browsers, manual pagers, terminfo libraries, etc., are
> >
> > Yes, but where is the info program that looks in both directories?
> > Before saying "this must
Santiago Vila <[EMAIL PROTECTED]> writes:
> On 10 Oct 1998, Adam P. Harris wrote:
> > 2. info browsers, manual pagers, terminfo libraries, etc., are
>
> Yes, but where is the info program that looks in both directories?
> Before saying "this must be done in this way" I would like to be sure that
>
Hi,
>>"Ian" == Ian Jackson <[EMAIL PROTECTED]> writes:
Ian> It doesn't necessarily mean having everything spread all over
Ian> the user's disk during the transition, unless we can't help it.
Actually, having things partially in /usr/man and partially in
/usr/share/man (if that is what
On 10 Oct 1998, Adam P. Harris wrote:
> 2. info browsers, manual pagers, terminfo libraries, etc., are
Yes, but where is the info program that looks in both directories?
Before saying "this must be done in this way" I would like to be sure that
effectively it may be done and someone will do it.
On Thu, 15 Oct 1998, Ian Jackson wrote:
> > We have discussed this before, but it seems that you missed the discussion
> > at all: If man and info are modified so that they support both old and new
> > locations, we will not have to symlink anything, and we will not need to
> > copy a lot of files
Santiago Vila writes ("Re: FHS - transition"):
...
> I strongly disagree. In fact, I see this as a contradiction to your
> earlier post, in which you said: "no `flag day', no moving everything at
> once".
I think you've missed my point(s) rather.
No flag da
Santiago Vila <[EMAIL PROTECTED]> writes:
> On Tue, 6 Oct 1998, Ian Jackson wrote:
> > (See also my post to debian-devel about this. In particular, I'm
> > opposed to /var/state and think we should ignore the FHS on this
> > point.)
> >
> > One of the key changes that the FHS has compared to the
Ian Jackson <[EMAIL PROTECTED]> wrote:
> (See also my post to debian-devel about this. In particular, I'm
> opposed to /var/state and think we should ignore the FHS on this
> point.)
...
> 3. base-files is changed so that /usr/man et al are symlinks to
> /usr/share/man, instead, with check in the
On 06-Oct-98 Ian Jackson wrote:
> (See also my post to debian-devel about this. In particular, I'm
> opposed to /var/state and think we should ignore the FHS on this
> point.)
So what is CURRENT policy? To follow FSSTND or FHS?
==
On Tue, 6 Oct 1998, Ian Jackson wrote:
> (See also my post to debian-devel about this. In particular, I'm
> opposed to /var/state and think we should ignore the FHS on this
> point.)
>
> One of the key changes that the FHS has compared to the FSSTND is the
> existence of /usr/share. I think thi
35 matches
Mail list logo
