On Tue, 2010-03-02 at 14:39 +0100, Jonas Meurer wrote: > i'm very sorry in case that my reply appeared offending to you. I'm actually not offended,... it's just that we apparently have different philosophies regarding coding style... and as you said you won't include the scripts in that style, but perhaps write your owns at a later time... I thought the bug should be closed (as it was just an inclusion request.
You see that my style is more like better document things twice and even make notes why some things were done in a specific way as I consider little documented code to be a bad thing... even for small scripts like those. And I've often seen the case (especially in Debian) that even the maintainer forgot why some things were written in a specific way and it's hard to get away with such code then. Another thing are my checks (like checking dpkg DB)... it is my philosophy that everything should be checked and handled in the proper place with proper error messages. This makes the code bigger and more complex, but who knows e.g. if initramfs-tools will forever tell people whether a program could not be found. Or people may just ignore this as they think it's not important... Last but not least,...mightiness: You've seen that I've added some code for option parsing (including the timeout stuff). Some might say that this is too much for something like cryptsetup, but I personally prefer to have a mighty system that allows many things and has many features. btw: I do not see why the timeout thingy as I use it makes any problems? It's just the timeout used with passdev in waiting for the device,.. nothing else and I do not claim the opposite (at least I hope so). And I'd say it's useful to let passdev timeout if e.g. someone does cryptdisk_start after the system is already up, and he does not want to wait infinitely for an usb stick to be inserted... I clearly see that your points (keeping everything small (thus a little bit more performant and maintainable) are also quite good... and I did not want to "convince you" or somehow show that my points are better in the text above. We have just different habits and interests and in the end, you're the maintainer... and I fully respect your decision. > and i really > appreciate the work you spent in developing them. i was also very happy > to see your replies to other bugreports. I will continue both (as far as my time allows it) :) The developing of the former scripts however only for me and my friends and colleagues at the institute who already use them > in fact you're the only one who > seems to be interested in the overal quality of the package. What's the english translation of the German "Zu viele Blumen! *rot werd*" ;) > so if you're not too much disappointed, I'm not,.. I had to write those scripts anyway for myself (well I would have perhaps omitted the readme in that case). I just thought it might be worth to share, especially as until know there is now comparable script with the same features. > i would be very happy to work > together with you on a version of the gnupg implmentation that satisfies > both of us. At the moment my time is quite limited as I have to perpare several lectures... and as I already have a solution which works perfectly for my different needs... you know ;) Anyway I strongly believe that if you want to provide similar features (avoid storing the key/passphrases to files, catch (probably exotic) errors by gpg, etc.) you'll have to do at least similar things. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
