Manoj Srivastava wrote: > I think that we would need a clear policy of what packages are > expected to do as well. Policy does not mandate that helper packages be > used in Debian packages, and we can't suddenly start mandating that > they be used.
I think you misunderstood it. The archive would start to accept .ddebs, but they won't be mandatory. Then packages using debhelper/whatever would build .ddeb packages if appropriate, but packages not using helper tools would keep working as they do now, not building .ddebs (not automatically by debhelper at least, but they could build them manually or use some other mechanism) and would still be accepted. So nothing would be forced to use helper tools. It's rather that if you want automatic .ddeb packages, you can get them with debhelper, but you can build them manually or use something else if you wish. Not ideal, but I haven't found a better alternative. > So, we figure out first exactly what needs to be done, and then > the helper packages implement that standard; as opposed to the standard > being whatever the current helper package implementation happens to be. That would be, packages may start to build .ddeb packages. Then helper tools or packages themselves can do the work to build them. For helper tools, we would get them automatically without any changes to the packages themselves, and that's something around 97% of the archive. > I am not sure if an existing dpkg tool can be modified to do > this, but I would be delighted to be proved wrong. Even if it was possible, you still wouldn't get 100% coverage, as not every package uses dpkg-dev. So this is the same problem as with helper tools, except that with helper tools, packages not using them can build .ddebs manually (or automatize it somehow). I don't know how it could be implemented in dpkg-dev anyway. dpkg-buildpackage sounds like the right place to do it, but before it calls the binary target is too soon, and after it is too late. Cheers, Emilio
signature.asc
Description: OpenPGP digital signature
