Chris Waters <[EMAIL PROTECTED]> wrote:
>On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:
>> - A change in the policy to remove the obsolete /usr/doc symlinks.
>
>This is supposed to happen once enough packages make the transition.
>Now, if we're really down to 253 packages that use /us
>>"Seth" == Seth Arnold <[EMAIL PROTECTED]> writes:
Seth> Is this working under the assumption that the release manager will drop
Seth> all packages "not recent enough" when freezing?
The assumption is that the release manager shall come up with
whatever criteria seem reasonable to him
* Manoj Srivastava <[EMAIL PROTECTED]> [010507 13:53]:
> field; and using the standards version field as a reason ti file bugs
> is just plain wrong.
Is this working under the assumption that the release manager will drop
all packages "not recent enough" when freezing?
--
Earthlink: The #1 pro
he FHS before we can confidently claim
> > FHS compatibility (and even *begin* to work on actual compliance).
> Reading the last three sentence I'm glad to hear that you volunteer to do
> all this checks...
I'm not the one who came here saying, "I want to suggest to fin
>>"Adrian" == Adrian Bunk <[EMAIL PROTECTED]> writes:
Adrian> In the source package's `Standards-Version' control
Adrian> field, you must specify the most recent version number
Adrian> of this policy document with which your package
Adrian> complies. The current version
On Sun, May 06, 2001 at 03:52:57PM -0500, Steve Greenland wrote:
> Uhh, when did that become a "must"? In 3.5.2 the first paragraph
> says
>
Probably during the policy/packaging merger. I intend at some point
to go through policy and fix all of these confusions. Furthermore, it
makes no sen
On Mon, May 07, 2001 at 11:19:57AM +0200, Adrian Bunk wrote:
> > Standards-Version you have, you still have to follow the FHS, you have
> > to use /usr/share/doc, and if you specify build-dependencies they have
> > to be correct.
> That means you can file RC bugs on all packages that don't follow t
On Mon, 7 May 2001, Anthony Towns wrote:
>...
> Standards-Versions aren't release critical. You can put it as
> "Standards-Version: 526.7.8.9.13-Foo.6" if you want. And no matter what
I will practice your suggestion and upload my packages with
"Standards-Version: 526.7.8.9.13-Foo.6".
> Standards
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:
> List of packages with Standards-Version < 3.0
>
> <-- snip -->
> [...]
> Torsten Landschoff ([EMAIL PROTECTED]) gsfonts-other
> Torsten Landschoff ([EMAIL PROTECTED]) gsfonts
Guess I should really upload
On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote:
> Standards-Version < 3 :
> a not FHS compliant package is at most a "normal" bug
> Standards-Version >= 3:
> a not FHS compliant package is at most a "serious" bug
This is not correct. You can't change the severity of a bug by twiddling
Hi Adam!
You wrote:
> Actually, I already did a mass bug filing, on the usr/doc issue(did a grep on
> Contents-i386, which wasn't fully accurate(other archs, stale data(up to a
> week or so))). I have seen several of the bugs closed, probably more than
> half now. I need to do another scan, to
On Sun, 6 May 2001, Chris Waters wrote:
> > > Didn't we already have this discussion? The Standards-Version field
> > > is not a reliable indication of much of anything. I strongly object
>
> > Policy says:
>
> "Policy says" doesn't make the packages comply. And you can file all
> the bugs repo
On Sun, 6 May 2001, Joey Hess wrote:
> Chris Waters wrote:
> > > - A change in the policy to remove the obsolete /usr/doc symlinks.
> >
> > This is supposed to happen once enough packages make the transition.
>
> No, it is supposed to happen one release _after_ a release in which all
> the package
On Sun, 6 May 2001, Chris Waters wrote:
> This is supposed to happen once enough packages make the transition.
> Now, if we're really down to 253 packages that use /usr/doc (with no
> symlink), then maybe it's time. But, unfortunately, that number, 253,
> measures *claimed* compliance, not actual
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote:
> Policy says:
> In the source package's `Standards-Version' control field, you must
> specify the most recent version number of this policy document with
> which your package complies. The current version number is 3.5.4.
On Sun, May 06, 2001 at 06:29:05PM -0400, Joey Hess wrote:
> Chris Waters wrote:
> > > - A change in the policy to remove the obsolete /usr/doc symlinks.
> > This is supposed to happen once enough packages make the transition.
> No, it is supposed to happen one release _after_ a release in which
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote:
> On Sun, 6 May 2001, Chris Waters wrote:
> > Didn't we already have this discussion? The Standards-Version field
> > is not a reliable indication of much of anything. I strongly object
> Policy says:
"Policy says" doesn't make the p
* Adrian Bunk <[EMAIL PROTECTED]> [20010506 21:27]:
> See above: I want to file a RC bug either because
> a) the package follows a too old policy or
For the /usr/doc problem, bugs with severity: normal have already been
filed by doogie and joeyh. For these packages, you simply have to
change the
Chris Waters wrote:
> > - A change in the policy to remove the obsolete /usr/doc symlinks.
>
> This is supposed to happen once enough packages make the transition.
No, it is supposed to happen one release _after_ a release in which all
the packages have made the transition. So sarge at the earlie
On 06-May-01, 14:27 (CDT), Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Policy says:
>
> <-- snip -->
>
> In the source package's `Standards-Version' control field, you must
> specify the most recent version number of this policy document with
> which your package complies. The curren
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote:
> Policy says:
>
> <-- snip -->
>
> In the source package's `Standards-Version' control field, you must
> specify the most recent version number of this policy document with
> which your package complies. The current v
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:
> If noone has a good argument against this I'll send
> RC bugs in one week to force the upgrade of the Standards-Version.
The packages inetutils, gnumach, hurd and mig are only applicable to the Hurd,
and we have not determined yet
On Sun, May 06, 2001 at 09:13:26PM +0200, Arthur Korn wrote:
> /usr/lib/menu is not shareable
Yes, it is. There's a reason why each entry starts:
?package()
Anyway, that's not really relevent -- /usr/share is for
architecture-independent static files. The FHS doesn't grant
exceptions for fi
On Sun, 6 May 2001, Chris Waters wrote:
> > I want to suggest to finish the FHS transition. This includes the
> > following steps:
>
> > - Packages with Standards-Version >= 3.0 must follow the FHS.
>
> Didn't we already have this discussion? The Standard
Chris Waters schrieb:
> (Plus, as a side issue, by a strict reading of the FHS, we should be
> using /usr/share/menu rather than /usr/lib/menu, which means RC bugs
> against nearly every package in the system!) :-)
/usr/lib/menu is not shareable, since it would be most confusing
to have a menu it
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote:
> I want to suggest to finish the FHS transition. This includes the
> following steps:
> - Packages with Standards-Version >= 3.0 must follow the FHS.
Didn't we already have this discussion? The Standards-Versi
Adrian Bunk wrote:
...
>Oliver Elphick ([EMAIL PROTECTED]) libpgsql
This package is obsolete and should not be included in any release.
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 102
Hi,
I want to suggest to finish the FHS transition. This includes the
following steps:
- Packages with Standards-Version >= 3.0 must follow the FHS.
Policy version 3.0.0.0 was released 30 Jun 1999 and I consider this
enough time for every maintainer to switch to at least this
Standa
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.
>
>
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 % [EM
Hi,
I've seen some people claim that the FHS transition issue has been
handled, but we still don't have a policy for it. I personally don't
feel comfortable drafting a policy but I will if no one else does.
At the moment, there does not even exist a /usr/doc/lintian, and p
[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.
eing there
forever. I don't think it would be true if we say that our system
is FHS but our individual packages are not.
For this reason I'm definitely think that making symlinks from the *new*
place to the *old* one in the FHS transition (first item in your
proposal) is not a good idea.
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
(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 this is perfectly appropriate, but
it will take some ef
65 matches
Mail list logo
