On Wed, Aug 12 2009, Roger Leigh wrote:
> On Wed, Aug 12, 2009 at 10:10:43AM -0500, Manoj Srivastava wrote:
>> On Wed, Aug 12 2009, Neil Williams wrote:
>>
>> > On Wed, 12 Aug 2009 08:22:17 -0500
>> > Manoj Srivastava <sriva...@debian.org> wrote:
>> >
>> >> > In many cases, wouldn't such a relationship be better expressed by a
>> >> > dependency on a package that implemented the new behaviour? Often it's
>> >> > dpkg and many of those situations are already handled via just such a
>> >> > dependency. So why have the extra field?
>> >>
>> >> Because not all new policy changes are reflected by a new
>> >> version of some package? And for Developer picking up a package and
>> >> wanting to know what needs to be looked at in order to achieve policy
>> >> compliance, a mess of possible dependency relationships is a lot harder
>> >> to base that decision on than a simple standards version.
>> >
>> > OK, so if it's mainly for the benefit of the (next) maintainer, why not
>> > leave the field in debian/ but not put it into the Sources.gz file and
>> > not make an issue of it if it is out of date? ould be a comment in
>> > debian/rules.
>>
>> I do not have a strong opinion about this, apart from the fact
>> that it must be present in the sources when someone is looking to
>> update the package, and it should be accessible before downloading all
>> the sources. So having it in the diff.gz and PTS would be good enough.
>
> The only /real/ use for the standards version is using it as a starting
> point for upgrading to the current standards version, and that's already
> making the (rather naïve) assumption that it was already fully conforming
> with Policy to begin with.
I donot think it is a naive assumption at all. The commohn case
with most package uploads is that the previous maintainer is the
current maintainer. Usually, I try to make sure that my package is
policy compliant (don't we all? we signed up for it). Then I see what
has changed in policy since then, and try to ensure that the package
still complies with policy.
Now, I can still make mistakes, and leave room for others to
notice and file bugs, but the primary process is still to look at
policy and proactively fix policy related bts, not wait for people to
find them for me and file bugs.
Minimizing the reading I need to do (by checking what has
changed in policy since I last checked policy) is a nice, useful
optimization.
>> I also do not see much of a downside in letting current practice
>> be -- what are the things I am missing?
>
> For most packages, it's typically the case that a new version of Policy
> requires no package changes, yet one needs to trawl through the changes
> in the upgrading checklist and then update the version number in the
> control file. Basically busy-work with no actual benefit; it's just
> pointless make-work for the maintainer.
Keeping packages policy compliant is one of the tasks that
maintainers must do -- apart from the trawling through
copyrights, making sure all configuration files live in /etc -- comes
with the territory.
> We have an automated method for checking Policy compliance: lintian.
> I'd far prefer that Policy transgressions were reported first and
> foremost by lintian rather than requiring manual (and potentially
> less reliable) checking by the maintainer. Rather than depending
> upon the maintainer's diligence, Policy conformance would then be
> assessed by automated checking than the presence of a number, which
> is of potentially unreliable provenance in the first place.
Lintian does not provide full coverage, and it can't. Some
policy dictums do not have a lintian check. Looking over the policy
changes seems like a decent addendum. By all means run lintian, but
nothing actually beats a human paying attention. Quality of
implementation improves. Deban developers ought to be acting like they
could be replaced by a small script (a t shirt I own).
manoj
--
"I think there is a world market for maybe five computers." Thomas
Watson, chairman of IBM, 1943
Manoj Srivastava <sriva...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
