[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

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

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.

Stefan



Reply to: