Re: Finishing the FHS transition
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
xtifr@debian.org | microscopicsilico- to fit into a single
or xtifr@speakeasy.net | volcaniconi- standalone haiku
Reply to: