Re: Finishing the FHS transition

[Chris Waters]

On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote:

> but you can't file 1060 RC bugs at the beginning of a freeze.

Why would you want to?  File 1060 normal bugs before the freeze! (If
you must file 1060 bugs at all -- I hope that's not a habit of yours.)
If we want, we can adjust the severity at freeze time, when,
hopefully, many of those bugs will have been closed.  Or we can say,
"there's just too many left open, realistically, we'll have to leave
this for the next release."

And you still seem to be implying that filing bugs fixes things.  I
may have to retract my earlier apology.  Filing RC bugs _is_ asking
for packages to be removed (especially this close to a freeze) unless
you're planning to NMU if necessary, or know for a fact that someone
else *will* fix the problem.  Saying "oh, it'll just get fixed at the
next bug-squashing party" is a seriously irresponsible attitude, IMO.

For a problem affecting that many packages, I'd rather tackle policy
and see about getting a change that would allow those packages to
remain in the system for a while longer.

> > Note that the next paragraph mentions filing bug reports if the
> > package becomes "too much out of date".  If any is too much, why
> > bother to say "too much"?

> You mustn't have to upgrade the Standards-Version field when your package
> doesn't comply with a more recent policy -> a package that doesn't follow
> FHS will never rech Standards-Version 3.0 .

I'm having trouble parsing that.  It sounds like you're saying that
you think it means that if a change in policy does not affect your
package, you *must* reupload to change Standards-Version immediately
or it's an RC bug, but if a change in policy *does* affect your
package, then you don't have to reupload, and it's not a bug at all?

That would be insane.

Policy is not the word of God.  It's our feeble attempt to codify what
we consider to be best practices.  And it needs to be read in that
light.  If your interpretation of policy leads to an insane
conclusion, it's time to ask for a clarification or correction, not to
blindly engage in insane behavior.

> > Bottom line, I think there remains a lot of work checking the subtle
> > and not-so-obvious stuff in the 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 finish the
FHS transition."  And I'm not the one who came up with a simple
two-step plan which fails to achieve that.

Yes, I have been working on the issue.  No, I probably can't do it
alone.  If you don't want to help, that's fine.  But when someone who
has been studying the issue for the last year tells you that it's not
so easy, maybe -- just maybe -- you should consider listening.

cheers
-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: Finishing the FHS transition

[Manoj Srivastava]

>>"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 number is 3.5.4.0. 

My opinion about the intent that this was meant to convey is
 that when you are building your package, update the standards
 version field to reflect what you comply with.

 Adrian>  This information may be used to file bug reports
 Adrian>  automatically if your  package becomes too much out of date.

I think this is a flaw in our current policy, and needs to be
 changed. If a package has no bugs (including policy violation bugs
 resulting from not following other must or should directives), then
 it should not need to be updated to just change the standards version
 field; and using the standards version field as a reason ti file bugs
 is just plain wrong.

manoj   
-- 
 What's a cult?  It just means not enough people to make a
 minority. Robert Altman
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Finishing the FHS transition

[Julian Gilbey]

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 sense for the issue to be talked about in two different
places, either.

   Julian

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

 Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
   Debian GNU/Linux Developer,  see http://people.debian.org/~jdg
  Donate free food to the world's hungry: see http://www.thehungersite.com/

Re: Finishing the FHS transition

[Tollef Fog Heen]

* Torsten Landschoff 

| On Mon, May 07, 2001 at 12:53:50AM +0100, Martin Michlmayr wrote:
|  
| > Package: gsfonts
| > Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
| >   91489 Package gsfonts still has at least one file in /usr/doc
| 
| Package is ready so far and installed locally. But I can't build a
| new package since /usr/bin/install suddenly decided to stop working *arg*

Broken fileutils - install the one in incoming or the one which went
into unstable last evening.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: Finishing the FHS transition

[Adrian Bunk]

On Mon, 7 May 2001, Torsten Landschoff wrote:

> On Mon, May 07, 2001 at 12:53:50AM +0100, Martin Michlmayr wrote:
>
> > Package: gsfonts
> > Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
> >   91489 Package gsfonts still has at least one file in /usr/doc
>
> Package is ready so far and installed locally. But I can't build a
> new package since /usr/bin/install suddenly decided to stop working *arg*
>...

This bug is fixed in fileutils version 4.1-2 that is in the archive since
yesterday evening.

> cu
>   Torsten

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Finishing the FHS transition

[Anthony Towns]

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 the FHS,
> independent from the Standards-Version?

More or less. The less part is when the FHS doesn't really offer a better
alternative (for things like /var/cvs), or things where we're not aiming
for exact compliance (like having symlinks in /usr/doc, rather than not
having anything). That's still independent of Standards-Version, though.

Policy still needs to be changed to say that documentation should be
referenced from /usr/share/doc rather than /usr/doc, iirc.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpbS0U1aihul.pgp
Description: PGP signature

Re: Finishing the FHS transition

[Torsten Landschoff]

On Mon, May 07, 2001 at 12:53:50AM +0100, Martin Michlmayr wrote:
 
> Package: gsfonts
> Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
>   91489 Package gsfonts still has at least one file in /usr/doc

Package is ready so far and installed locally. But I can't build a
new package since /usr/bin/install suddenly decided to stop working *arg*

> Package: gsfonts-other
> Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
>   91485 Package gsfonts-other still has at least one file in /usr/doc

Likewise.

cu
Torsten


pgpT3rcxmk2R0.pgp
Description: PGP signature

Re: Finishing the FHS transition

[Adrian Bunk]

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-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 the FHS,
independent from the Standards-Version?

> Cheers,
> aj

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Finishing the FHS transition

[Torsten Landschoff]

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 my local packages :)

Greetings

Torsten


pgpGAIVzC0G2m.pgp
Description: PGP signature

Re: Finishing the FHS transition

[Anthony Towns]

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
a field with a purely indicative use.

> > We have many packages with old Standards-Versions which actually
> > comply with newer standards and *are* FHS compatible, and we have
> > packages with newer Standards-Versions that are NOT FHS compatible.
> Please file RC bug on packages with Standards-Version >= 3 that are not
> FHS compatible.

No. Don't. I'll just downgrade them as soon as I see them, so you'll
be just wasting your own time and mine. Policy is simply wrong in using
the word "must" in regards to the "Standards-Version" field.

And no, this isn't an opportunity for discussion. Everything there is
to be said on this matter has been said, repeatedly. Check the -policy
archives if you really must.

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
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.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
I don't speak for anyone save myself. GPG signed mail preferred.

``_Any_ increase in interface difficulty, in exchange for a benefit you
  do not understand, cannot perceive, or don't care about, is too much.''
  -- John S. Novak, III (The Humblest Man on the Net)


pgpR12t7DVI1B.pgp
Description: PGP signature

Re: Finishing the FHS transition

[Bas Zoetekouw]

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 see where we stand on that.

There is already a list on http://qa.debian.org/fhs.html

-- 
Kind regards,
+---+
| Bas Zoetekouw  | Si l'on sait exactement ce   |
|| que l'on va faire, a quoi|
| [EMAIL PROTECTED] | bon le faire?|
|[EMAIL PROTECTED] |   Pablo Picasso  |
+---+ 

Re: Finishing the FHS transition

[Adrian Bunk]

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 reports you want, but that doesn't magically fix the
> packages.  And until they're fixed, you can't use them as a reliable
> indicator of FHS compatibility.  QED.

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

> We have many packages with old Standards-Versions which actually
> comply with newer standards and *are* FHS compatible, and we have
> packages with newer Standards-Versions that are NOT FHS compatible.

Please file RC bug on packages with Standards-Version >= 3 that are not
FHS compatible.

> I think that if you really want to focus on FHS compatibility, you're
> better off ignoring the Standards-Version issues for now.  Its just
> another can of worms.  Picking the minimum Standards-Version for
> release is something we normally do at freeze time.

I think it's important that our packages follow a not too outdated policy
and the "Standards-Version" field is the indicator for this. Freeze time
is too late for picking the minimum Standards-Version for release - the
right time would be shortly after the last stable was released. An
example: It would be nice to have a minimum Standards-Version of 3.1 (that
includes build dependencies), but you can't file 1060 RC bugs at the
beginning of a freeze.

>...
> Note that the next paragraph mentions filing bug reports if the
> package becomes "too much out of date".  If any is too much, why
> bother to say "too much"?

You mustn't have to upgrade the Standards-Version field when your package
doesn't comply with a more recent policy -> a package that doesn't follow
FHS will never rech Standards-Version 3.0 .

> > > to removing packages because of what amount to cosmetic issues, and an
>
> > Where did I say that I want to remove the packages???
> > I said that I want to send bug reports.
>
> RC bugs mean the package must be removed from the next release if it's
> not fixed.  Unless you can guarantee that the bugs will be fixed
> (i.e., you're volunteering to fix them yourself), you _are_ asking for
> package to be removed when you file RC bugs.

These bugs are relatively easy to fix bugs and many of them will be fixed
at a bug squashing party - and yes, I do fix many "easy to fix bugs" at
each bug squashing party. But BTW: When a maintainer doesn't even when
there's a RC bug starts to work on upgrading the package to comply with a
policy that is nearly two years old there's the question of he's MIA.

> Anyway, I apologize for a reminder I'm sure you don't need.  It's just
> a habit of mine, please forgive me.
>
> Bottom line, I think there remains a lot of work checking the subtle
> and not-so-obvious stuff in the 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...

>...
> And I think mass filings of RC bugs would be premature at best.

It's perhaps really late because we are relatively close too a freeze but
it's definitely not premature.

> cheers

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Finishing the FHS transition

[Tollef Fog Heen]

* Adam Heath 

| Um, when was it decided that woody+1=sarge?  When was this flamewar?

It wasn't yet.  aj needed a name for woody+1 and picked sarge as an
interim name.

-- 

Tollef Fog Heen
Unix _IS_ user friendly... It's just selective about who its friends are.

Re: Finishing the FHS transition

[Adam Heath]

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 packages have made the transition. So sarge at the earliest, not woody.

Um, when was it decided that woody+1=sarge?  When was this flamewar?

Re: Finishing the FHS transition

[Adam Heath]

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 compliance.
>
> Now, my poking around suggests that there are actually far *fewer*
> than 253 packages still using /usr/doc.  And if that's true, then it's
> definitely time to remove the symlinks.  But it might be nice to have
> some hard facts, rather than speculation based on unreliable claims
> made by inattentive package maintainers.

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 see where we stand on that.

Re: Finishing the FHS transition

[Chris Waters]

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
> all the packages have made the transition. So sarge at the earliest,
> not woody.

Right.  Even better point.
-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: Finishing the FHS transition

[Chris Waters]

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 packages comply.  And you can file all
the bugs reports you want, but that doesn't magically fix the
packages.  And until they're fixed, you can't use them as a reliable
indicator of FHS compatibility.  QED.

We have many packages with old Standards-Versions which actually
comply with newer standards and *are* FHS compatible, and we have
packages with newer Standards-Versions that are NOT FHS compatible.

I think that if you really want to focus on FHS compatibility, you're
better off ignoring the Standards-Version issues for now.  Its just
another can of worms.  Picking the minimum Standards-Version for
release is something we normally do at freeze time.

>  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.0.

You're misinterpreting this.  It does not mean that every package must
be reuploaded every time policy changes.  "Most recent" should be
checked at the time you create the source package, not rechecked
daily.

Note that the next paragraph mentions filing bug reports if the
package becomes "too much out of date".  If any is too much, why
bother to say "too much"?

> > to removing packages because of what amount to cosmetic issues, and an

> Where did I say that I want to remove the packages???
> I said that I want to send bug reports.

RC bugs mean the package must be removed from the next release if it's
not fixed.  Unless you can guarantee that the bugs will be fixed
(i.e., you're volunteering to fix them yourself), you _are_ asking for
package to be removed when you file RC bugs.

Anyway, I apologize for a reminder I'm sure you don't need.  It's just
a habit of mine, please forgive me.

Bottom line, I think there remains a lot of work checking the subtle
and not-so-obvious stuff in the FHS before we can confidently claim
FHS compatibility (and even *begin* to work on actual compliance).

The easy stuff, as your evidence shows, we're actually quite close on.
It's the harder stuff, like /var/lib/games (which Kamion was going to
investigate) and the random hard-to-identify files that need to move
from /usr/lib to /usr/share that needs the most attention.

So, anyway, that's a nice list of packages you made, and I think it's
probably very useful -- all those packages should inspected -- I just
don't think it's very useful for the purpose you intended.

And I think mass filings of RC bugs would be premature at best.

cheers
-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: Finishing the FHS transition

[Martin Michlmayr]

* 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 severity.  At the moment, 103 of these bugs are still open
(248 bugs were filed originally):


Package: acm
Maintainer: Enrique Zanardi <[EMAIL PROTECTED]>
  91371 Package acm still has at least one file in /usr/doc
  91382 Package acm still has at least one file in /usr/doc

Package: authbind
Maintainer: Ian Jackson <[EMAIL PROTECTED]>
  91376 Package authbind still has at least one file in /usr/doc
  91387 Package authbind still has at least one file in /usr/doc

Package: bock
Maintainer: Charles Briscoe-Smith <[EMAIL PROTECTED]>
  91396 Package bock still has at least one file in /usr/doc

Package: cqcam
Maintainer: Daniel Martin <[EMAIL PROTECTED]>
  91415 Package cqcam still has at least one file in /usr/doc

Package: cracklib-runtime
Maintainer: Jean Pierre LeJacq <[EMAIL PROTECTED]>
  91407 Package cracklib-runtime still has at least one file in /usr/doc

Package: cracklib2
Maintainer: Jean Pierre LeJacq <[EMAIL PROTECTED]>
  91414 Package cracklib2 still has at least one file in /usr/doc

Package: cracklib2-dev
Maintainer: Jean Pierre LeJacq <[EMAIL PROTECTED]>
  91429 Package cracklib2-dev still has at least one file in /usr/doc

Package: csound-doc
Maintainer: Guenter Geiger <[EMAIL PROTECTED]>
  91433 Package csound-doc still has at least one file in /usr/doc

Package: cup
Maintainer: Charles Briscoe-Smith <[EMAIL PROTECTED]>
  91422 Package cup still has at least one file in /usr/doc

Package: doc-debian-fr
Maintainer: Christophe Le Bars <[EMAIL PROTECTED]>
  91417 Package doc-debian-fr still has at least one file in /usr/doc

Package: dtlk
Maintainer: [EMAIL PROTECTED] (James R. Van Zandt)
  91438 Package dtlk still has at least one file in /usr/doc

Package: dtmfdial
Maintainer: [EMAIL PROTECTED] (Stephen J. Carpenter)
  91450 Package dtmfdial still has at least one file in /usr/doc

Package: dvidvi
Maintainer: [EMAIL PROTECTED] (David A. van Leeuwen)
  91439 Package dvidvi still has at least one file in /usr/doc

Package: emacs20-el
Maintainer: Rob Browning <[EMAIL PROTECTED]>
  91554 Package emacs20-el still has at least one file in /usr/doc

Package: emacsen-common
Maintainer: Rob Browning <[EMAIL PROTECTED]>
  91457 Package emacsen-common still has at least one file in /usr/doc

Package: f77reorder
Maintainer: Alex Romosan <[EMAIL PROTECTED]>
  91444 Package f77reorder still has at least one file in /usr/doc

Package: faqomatic
Maintainer: [EMAIL PROTECTED] (Scott K. Ellis)
  91465 Package faqomatic still has at least one file in /usr/doc

Package: ftape-doc
Maintainer: Christian Meder <[EMAIL PROTECTED]>
  91463 Package ftape-doc still has at least one file in /usr/doc

Package: ftape-util
Maintainer: Christian Meder <[EMAIL PROTECTED]>
  91462 Package ftape-util still has at least one file in /usr/doc

Package: gap4-gdat
Maintainer: Markus Hetzmannseder <[EMAIL PROTECTED]>
  91470 Package gap4-gdat still has at least one file in /usr/doc

Package: gap4-tdat
Maintainer: Markus Hetzmannseder <[EMAIL PROTECTED]>
  91469 Package gap4-tdat still has at least one file in /usr/doc

Package: gbdk-dev
Maintainer: Masato Taruishi <[EMAIL PROTECTED]>
  91472 Package gbdk-dev still has at least one file in /usr/doc

Package: gbdk-examples
Maintainer: Masato Taruishi <[EMAIL PROTECTED]>
  91471 Package gbdk-examples still has at least one file in /usr/doc

Package: gcc-m68k-linux
Maintainer: Martin Mitchell <[EMAIL PROTECTED]>
  91476 Package gcc-m68k-linux still has at least one file in /usr/doc

Package: gerstensaft
Maintainer: Martin Schulze <[EMAIL PROTECTED]>
  91477 Package gerstensaft still has at least one file in /usr/doc

Package: glimpse
Maintainer: Marco Budde <[EMAIL PROTECTED]>
  91484 Package glimpse still has at least one file in /usr/doc

Package: gs-aladdin-manual
Maintainer: Marco Pistore <[EMAIL PROTECTED]>
  91486 Package gs-aladdin-manual still has at least one file in /usr/doc

Package: gs-aladdin-manual-de
Maintainer: Marco Pistore <[EMAIL PROTECTED]>
  91483 Package gs-aladdin-manual-de still has at least one file in /usr/doc

Package: gsfonts
Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
  91489 Package gsfonts still has at least one file in /usr/doc

Package: gsfonts-other
Maintainer: Torsten Landschoff <[EMAIL PROTECTED]>
  91485 Package gsfonts-other still has at least one file in /usr/doc

Package: htget
Maintainer: Troy Hanson <[EMAIL PROTECTED]>
  91497 Package htget still has at least one file in /usr/doc

Package: id-utils
Maintainer: Brad Bosch <[EMAIL PROTECTED]>
  91555 Package id-utils still has at least one file in /usr/doc

Package: idled
Maintainer: John Goerzen <[EMAIL PROTECTED]>
  91513 Package idled still has at least one file in /usr/doc

Package: infocom

Re: Finishing the FHS transition

[Joey Hess]

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 earliest, not woody.

-- 
see shy jo

Re: Finishing the FHS transition

[Steve Greenland]

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 current version number is 3.5.4.0.
>
>  This information may be used to file bug reports automatically if your
>  package becomes too much out of date.
>
> <--  snip  -->

Uhh, when did that become a "must"? In 3.5.2 the first paragraph
says

 You should specify the most recent version of the packaging
 standards with which your package complies in the source package's
 `Standards-Version' field.

Even in 3.5.4, towards the end of that section it says
  
 You should regularly, and especially if your package has become out
 of date, check for the newest Policy Manual available and update   
 your package, if necessary. When your package complies with the new
 standards you should update the Standards-Version source package   
 field and release it.

It says nothing about uploading just to notify that you "are still
compliant".

Hmmm, I don't remember a proposal to change this; I suspect the "must"
slipped in during the recent rewrites, and as Chris Waters pointed out, it
is certainly inconsistent with the intent of the field according to recent
discussion.

> "you must specify the most recent version number of this policy document
> with which your package complies": You must upgrade this field when your
> package complies with a more recent policy - and when your package does
> already comply with a more recent policy nothing more than an upload with
> an updated Standards-Version field is needed.

Nonsense. I'm not going to upload new versions of packages simply to
change that field. Lot's of policy updates have zero effect on most
packages, and I doubt many of our users want to spend the time and
money downloading and installing a new version of a package to confirm
that.  I would strongly object if (for example) Branden suddenly started
uploading new versions of the X packages every time a new version of
policy was released.

I'll wait a few days for one of the policy editors to say "Oops, that
was an accident"; if that's not the case, I need to propose an ammendent
that clarifies reality, so that Adrian doesn't get mislead again :-).

Steve

-- 
Steve Greenland <[EMAIL PROTECTED]>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)

Re: Finishing the FHS transition

[Marcus Brinkmann]

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 version number is 3.5.4.0.
> 
>  This information may be used to file bug reports automatically if your
>  package becomes too much out of date.
> 
> <--  snip  -->

Ok, please ignore my other mail.

Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

Re: Finishing the FHS transition

[Marcus Brinkmann]

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 how much and what of the FHS is applicable to
us. Most of it is, but we might need an appendix for the Hurd just as there is
an appendix for Linux.

In any way, I will bump the number if it makes you happy on my next update,
and Jeff Bailey took over maintenance of GNU inetutils, he is
preparing an update, but I wouldn't consider an old standards
version a release critical bug.  You will have to bother and check each
package individually if there is actually a violation of current policy or
a critical bug that warrants a release critical bug report.

> GNU Hurd Maintainers (bug-hurd@gnu.org)  gnumach
> GNU Hurd Maintainers (bug-hurd@gnu.org)  hurd
> GNU Hurd Maintainers (bug-hurd@gnu.org)  mig
> Marcus Brinkmann ([EMAIL PROTECTED])inetutils

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

menu and FHS (was Re: Finishing the FHS transition)

[Chris Waters]

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 files that would cause breakage if they actually were
shared between different machines.

cheers
-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: Finishing the FHS transition

[Adrian Bunk]

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 Standards-Version field
> is not a reliable indication of much of anything.  I strongly object

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 version number is 3.5.4.0.

 This information may be used to file bug reports automatically if your
 package becomes too much out of date.

<--  snip  -->

> to removing packages because of what amount to cosmetic issues, and an

Where did I say that I want to remove the packages???
I said that I want to send bug reports.

> incorrect Standards-Version (one that doesn't reflect the version of
> policy that the package _actually_ complies with) is really no more
> than a cosmetic issue (no software actually uses that field).

"you must specify the most recent version number of this policy document
with which your package complies": You must upgrade this field when your
package complies with a more recent policy - and when your package does
already comply with a more recent policy nothing more than an upload with
an updated Standards-Version field is needed.

> I only have a few of the listed packages installed on my system, but
> most of the ones I checked did indeed use /usr/share/doc (and
> /usr/share/man, in those cases where man pages were present).  I
> suspect that this is due to the use of debhelper, but anyway
>
> Checking for FHS violations should be done by checking for FHS
> violations, not by checking an unreliable and all-but-meaningless
> field in some configuration file.
>...

See above: I want to file a RC bug either because
a) the package follows a too old policy or
b) because it violates the _must_ in the polict that says that the
   Standard-Version must get updated.

a) needs discussion whether we consider packages not following the FHS
"too much out of date", b) is a violation of the policy that doesn't need
discussion - that means the only question is whether anyone disagrees that
we want to have all packages in unstable to follow the FHS.

> cheers

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Finishing the FHS transition

[Arthur Korn]

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 item that just doesn't work, because the package
it belongs to is installed on another machine with which
/usr/share is shared.

ciao, 2ri
-- 
Q: How does a Unix guru have sex?
A: gunzip && strip && touch && finger && mount && fsck && \
   more && yes && fsck && fsck && fsck && umount && sleep

Re: Finishing the FHS transition

[Chris Waters]

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-Version field
is not a reliable indication of much of anything.  I strongly object
to removing packages because of what amount to cosmetic issues, and an
incorrect Standards-Version (one that doesn't reflect the version of
policy that the package _actually_ complies with) is really no more
than a cosmetic issue (no software actually uses that field).

I only have a few of the listed packages installed on my system, but
most of the ones I checked did indeed use /usr/share/doc (and
/usr/share/man, in those cases where man pages were present).  I
suspect that this is due to the use of debhelper, but anyway

Checking for FHS violations should be done by checking for FHS
violations, not by checking an unreliable and all-but-meaningless
field in some configuration file.

(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!)  :-)

> - 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 /usr/doc (with no
symlink), then maybe it's time.  But, unfortunately, that number, 253,
measures *claimed* compliance, not actual compliance.

Now, my poking around suggests that there are actually far *fewer*
than 253 packages still using /usr/doc.  And if that's true, then it's
definitely time to remove the symlinks.  But it might be nice to have
some hard facts, rather than speculation based on unreliable claims
made by inattentive package maintainers.

> Ben Gertzfield ([EMAIL PROTECTED])  wmifs
> Eric Leblanc ([EMAIL PROTECTED])groovycd
> Eric Leblanc ([EMAIL PROTECTED])zangband
> Gene McCulley ([EMAIL PROTECTED])  xcopilot
> Javier Fernandez-Sanguino Pen a ([EMAIL PROTECTED])   spellcast
> Luis Francisco Gonzalez ([EMAIL PROTECTED])  xgammon
> Rob Browning ([EMAIL PROTECTED]) emacs20
> Robert Woodcock ([EMAIL PROTECTED]) cd-discid
> Takuo KITAME ([EMAIL PROTECTED])   bbdb
> Vincent Renardias ([EMAIL PROTECTED])   gdb
> Vincent Renardias ([EMAIL PROTECTED])   gnumeric
> Wichert Akkerman ([EMAIL PROTECTED])   sed

I inspected these packages.  Only emacs20 lacked the /usr/share/doc
directory.  If that ratio holds true (which I doubt), then we've only
got 21 packages left to transition! :-)

cheers
-- 
Chris Waters   |  Pneumonoultra-osis is too long
[EMAIL PROTECTED]   |  microscopicsilico-to fit into a single
or [EMAIL PROTECTED] |  volcaniconi-  standalone haiku

Re: Finishing the FHS transition

[Adrian Bunk]

On Sun, 6 May 2001, Oliver Elphick wrote:

> Adrian Bunk wrote:
>  ...
>   >Oliver Elphick ([EMAIL PROTECTED])   libpgsql
>
> This package is obsolete and should not be included in any release.

Please ask the ftp admins to remove the package from unstable (file a bug
against ftp.debian.org).

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

Re: Finishing the FHS transition

[Oliver Elphick]

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: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47  6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
 
 "If it is possible, as much as it depends on you, live 
  peaceably with all men."Romans 12:18