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