Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? -- One does not see anything until one sees its beauty. -- Oscar Wilde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design
On Fri, Jul 28, 2006 at 10:03:13AM +0300, Lars Wirzenius wrote: pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? The dh_ file can be shipped with ssl-cert2, preferably under a name that doesn't invade debhelper's namespace. As the packages are going to depend on ssl-cert2, making them build-depend on it is not a real burden. -- 1KB // Q: How do you spot a good inetd? // A: It build-depends on equivs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
On (28/07/06 10:03), Lars Wirzenius wrote: pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? Why does this concern you? I thought debhelper was fairly standard use today. But, yes, like all of debhelper it's just a convenience wrapper. If your package is very simple then in the postinst add if [ $1 = configure ]; then make-ssl-cert2 package fi and in postinst if [ $1 = purge ]; then make-ssl-cert2 -r package || true fi The dh_ script merely does this for you after adding any extra arguments to make-ssl-cert that you have requested with your debian/package.certificate file. So, if you are merely concerned that it is /possible/ to do it without a dh_ call, then it certainly is. But I think it is a good idea to use it, as if the policy changes in this respect then a rebuild is all that may be required. And also it gives the maintainer more chance that any problems can simply be reassigned to someone else. James Westby [P.S. I have put the source in bzr format here http://jameswestby.net/bzr/ssl-cert2/ so it's browsable over the web now] -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
pe, 2006-07-28 kello 10:53 +0100, James Westby kirjoitti: On (28/07/06 10:03), Lars Wirzenius wrote: pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? Why does this concern you? I thought debhelper was fairly standard use today. I don't like it when people make using helper packages de facto required. And debhelper isn't standard (meaning that you can expect everyone to use it), merely very common. It is also very good, but its use must still remain optional. But, yes, like all of debhelper it's just a convenience wrapper. If your package is very simple then in the postinst add Good. If that is documented in the ssl-cert2 package, then all is well. -- The most difficult thing in programming is to be simple and straightforward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design [Was: Re: Using the SSL snakeoil certificate]
On (28/07/06 13:16), Lars Wirzenius wrote: pe, 2006-07-28 kello 10:53 +0100, James Westby kirjoitti: I don't like it when people make using helper packages de facto required. And debhelper isn't standard (meaning that you can expect everyone to use it), merely very common. It is also very good, but its use must still remain optional. That is fair enough. I understand the desire for choice. But, yes, like all of debhelper it's just a convenience wrapper. If your package is very simple then in the postinst add Good. If that is documented in the ssl-cert2 package, then all is well. http://jameswestby.net/bzr/ssl-cert2/README Probably requires updating to the new make-ssl-cert2 options. -- James Westby [EMAIL PROTECTED] http://jameswestby.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design
On Fri, 28 Jul 2006 10:53:22 +0100, James Westby [EMAIL PROTECTED] said: On (28/07/06 10:03), Lars Wirzenius wrote: pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti: * Make it easier for package maintainers - One extra dh_ call and maybe one more file in debian/ How badly is this tied to debhelper? Any chance of designing it so that it doesn't require debhelper? Why does this concern you? I thought debhelper was fairly standard use today. It concerns me since I do not use helper packages in my packaging. Debhelper, while pretty popular, is by no means mandatory, or universal. But, yes, like all of debhelper it's just a convenience wrapper. If your package is very simple then in the postinst add Well, my packages are not simple, but I still prefer to hand craft them. if [ $1 = configure ]; then make-ssl-cert2 package fi and in postinst if [ $1 = purge ]; then make-ssl-cert2 -r package || true fi The dh_ script merely does this for you after adding any extra arguments to make-ssl-cert that you have requested with your debian/package.certificate file. This is perfectly fine, as long as there is a man page for make-ssl-cert. So, if you are merely concerned that it is /possible/ to do it without a dh_ call, then it certainly is. But I think it is a good idea to use it, as if the policy changes in this respect then a rebuild is all that may be required. I would hope that such policy changes be very few, once stabilized, and any minor changes would be subsumed in make-ssl-cert. And also it gives the maintainer more chance that any problems can simply be reassigned to someone else. I prefer to actually maintain my packages, not seek excuses to reassign bug reports to other people. YMMV. manoj -- But was he mature enough last night at the lesbian masquerade? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: ssl-cert2 design
On (28/07/06 12:12), Manoj Srivastava wrote:
On Fri, 28 Jul 2006 10:53:22 +0100, James Westby [EMAIL PROTECTED] said:
On (28/07/06 10:03), Lars Wirzenius wrote:
pe, 2006-07-28 kello 00:03 +0100, James Westby kirjoitti:
But, yes, like all of debhelper it's just a convenience wrapper. If
your package is very simple then in the postinst add
Well, my packages are not simple, but I still prefer to hand
craft them.
Sorry, I mispoke slightly, I meant simple in terms of there certificate
requirements. That is happy just with a certificate in /etc/ssl/certs
and a key in /etc/ssl/private. Then it is very simple to do this. And
hopefully it is not too much more difficult for the packages that
require more than this (e.g. ftpd-ssl that required the cert and key to
be the same file, which should be easily possible with or without
debhelper).
This is perfectly fine, as long as there is a man page for
make-ssl-cert.
http://jameswestby.net/bzr/ssl-cert2/make-ssl-cert2.8
Requires a little tweaking, but then again so does the entire package.
I guess I must apologise for empasising the debhelper script in this,
all it dees is write the post{inst,rm} snippets for the maintainer. And
it is obviously possible for the maintainer to do this themselves.
Maybe I shouldn't have included the advantages to the package maintainer
comment in my summary. This is not the aim of the package, the aim is to
give the sysadmin more control and flexibilty about how to handle this
stuff, the benefits to the packager are just a result of using a central
system.
Obviously the maintainers are free to ignore this package completely,
but I hope it will be used as they will be able to see the benifits it
gives to the users.
I guess I should be happy that no-one has pointed out any flaws in my
design, or said that they do not wish to use the system. Then again this
might just mean that most people have ignored this thread.
Thanks,
James
--
James Westby
[EMAIL PROTECTED]
http://jameswestby.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
