reassign 340306 ftp.debian.org title 340306 archive rejects .deb packages with any additional member severity important thanks
* Jeroen van Wolffelaar <[EMAIL PROTECTED]> [2005-11-22 21:06]:
> Should != must.
But you have to have a good reason to ignore it. I haven't heard any
(real) reason at all for it during the former changes in that respect
which were reverted because there was no reason available, and it still
breaks existing functionality.
> Besides, Policy deals with packages' behaviour not with how the
> archive should behave.
So you are saying that the archive is allowed to actively work against
the policy? That's a very interesting point of view, and I don't think
that very much developers share that point of view. We could of course
start a GR/strawpoll for this, if you need it to be convinced that the
archive doesn't have to work against the policy, especially not with any
reasoning.
Besides, you reassigned the bugreport to a package, so you *do* believe
that it's a package's behaviour. Now what? Is is a package's behaviour or
is it not? You are inconsistent in your "reasoning", which sounds more
like looking for an excuse because there isn't any reason involved?
> In any case, I do not follow your reading of policy that would mandate
> debian.org's archive to allow extra members of .deb's.
Very fine. So you are for handing the responsibility about any future
extension like they are explicitly noted in the policy[1] over from the
people more invovled with it like package tool maintainers to the
archive maintainers?
You are actively hindering the inclusion for digital signatures here,
and in addition of any future extension that might come up, adding more
load to your work, and decision power of inclusion/not inclusion of
future features, which in my opinion shouldn't be yours (as in the
archive team, not you personally).
> Anyway, it seems work is underway to allow specifically dpkg-sig'd
> .deb's in the archive proper (rather than not checking extra members
> at all, with the potentional to contain any random sort of data that's
> not normally visible by usage of dpkg),
It is a good thing to add checking of like the signature that are known
now (against a quite broad pool of keys, mind you, there might not only
be signatures on the .deb that are in our keyring) and checking for bad
signatures. But not ignoring (yet) unknown parts to you is a very strong
change in the functionality and hinder any future development in any
direction at all. Again, I really don't thank that decision power and
especially even if they agree dealying process has to be the ftp team's
responsibility.
> once the code is there, this issue will be revisited. For now though,
> the check will remain in place.
So for now some people aren't able to upload their packages and fix
outstanding problems because they refuse to buy that regression. Very
convenient.
Thanks in advance for pulling more power to the ftp team and thinking
about if that's the way it should go. Besides, this is no wishlist
because the change disables usability that had been there for quite a
while (well over a year) and was actively used.
So long,
Alfie
[1] From Appendix B of policy:
In the future binary packages may also contain other components, such
as checksums and digital signatures. The format for the archive is
described in full in the `deb(5)' man page.
--
> Wozu ein Forum, wenn's Usenet gibt?
Keine Unterscheidung zwischen Multipost, Crosspost und vor allem kein
Followup-To mehr noetig - ist fuer professionelle Anwender eh zu komplex
-- Alexander Talos in <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
