Re: Policy progress
Manoj Srivastava wrote:
I would not want this to change. Anyone can make innovative
proposals, but the hard part is getting things to work -- and just
doing it. Debhelper, debconf, the whole testing distribution -- were
all proposed, and worked on, without first getting policy to bless
Yes, these are good examples for changes which don't need Policy's
blessing, e.g. you just need to convince the FTP admins if you want to
implement testing. However there are also a lot of counter examples of
features which need to be prescribed by Policy before they get implemented.
Two of these examples are MD5 sums and package signatures. Policy still
does not require packages to provide MD5 sums for all files in the
package. However, most of the packages on my system do provide
/var/lib/dpkg/info/*.md5sums but I still can't verify the integrity of
my system because a few packages don't provide them and so package
signatures can't be added. The technology is there, it is working well
-- it's just not required by Policy. Adamantix has shown that it can be
done now without waiting for the dpkg developers to implement it
directly in dpkg.
I see. debconf, debhelper, testing, the whole new bts system
-- not innovative, just because they do not fit into your theory?
I was talking about innovations that are visible to the end user, so
I've indeed forgotten debconf. debhelper is surely older than 4 years, I
remember that I've switched my first package from debstd to debhelper in
I see. Unless we can use policy to beat developers on the head
with RC bugs, we are stuck. (Never mind that RC bugs are not
determined by policy, but hey).
Come on, be serious. Just because a package is not Policy compliant
doesn't mean that the maintainer will be hurt. For example, the latest
Policy change that Build-Depends-Indep need not be satisfied during
clean caused a bit of work for most Java maintainers. Almost all Java
packages are architecure independent so they only had
Build-Depends-Indep in debian/control. Now we also need to add
Build-Depends since at least debhelper is called in the clean target.
Did it hurt? Did we complain? We just changed our packages (or will do
so in the next upload). According to your strategy, this change would
not have been allowed.
I thought that if a package violates a "must" requirement in the Policy
the bug will be RC. So yes, Policy determines the severity of bugs.
Therefore I suggest to accept changes to the Policy even if this
means that some packages suddenly violate the Policy. This of course
only makes sense when the required infrastructure (e.g. a features
in dpkg) is already there and the proposed change has proven to work
correctly in other packages (reference implementation).
I think this is a stunningly bad idea, for reasons I have
Could you please explain them again? The only one that I've found is
that you don't want to beat developers with RC bugs. The bugs won't be
RC if the packages are violating a "should" requirement.
Well, if you cannot convince the people who do the work, no,
it shall not get done. If the idea is so good, why would it be so
hard to convince the developers who maintain the packages that it is
a good idea?
Because there's always someone who disagrees. Even if 99% of all
developers agree, at last one of the 10 remaining developers will
formally object. :-(
If you want to rely on a feature like the status option for init script
(or MD5 sums), it needs to be implemented in all relevant packages. It
gains us nothing if I can convince 75% of the developers.