Sven Hoexter <[EMAIL PROTECTED]> writes: > To be clear there are two sides of the story to consider:
Thank you for your comprehensive account, trying to shed light on the situation! > a) The social/trust problem > There's someone providing binarys build on an unknown system with under > unknown conditions and you've to install those binarys as superuser. > So someone I don't know and by definition don't trust will do things > with superuser rights. That can't be good. You don't need to have to > be evil but you or your tool might do something bad. Indeed (as I had mentioned on the development list earlier today) any installation soever --from an "unknown"-- presents a serious security issues. To say it again: `At present all that can be "known", is that someone from a specific email address sends an announcement to the LyX list about a new binary being available. This indeed is not very safe, yet with each day that passes (without someone complaining on the list about the binary) and with every new binary announced--from one an the same email address--it becomes more and more "safe".' In addition, the more time passes, the more like it might be that someone will notice errors, malicious or not. What solution could you think of? Does the development team use key? > b) Technical problems I guess this is a specific debian issue you're raising and might differ at each distro (my apologies to for the possibly off-list-topic discussion here). > ba) You're breaking the upgrade path. > Let's say under bad conditions the next Debian stable release will be > delivered with LyX 1.5.3 packages. What do you guess happens on a > system with etch running your packages on the upgrade? Bingo nothing > for the LyX package because it has the same version number. > So there will be users with an untrusted package compiled with some > completly different libs not matching there current system. True, if you are using checkinstall binaries and (in the unlikely event of) your stable debian release upgrading to this specific lyx release, libraries might most probably not match. All you need to do is to reinstall, through the comfort of checkinstall the offending lyx package. sudo dpkg -r lyx > bb) Maintainer scripts have a reason > If you take a look at the diff.gz of the Debian packages you'll find > out that there are maintainer scripts for post/pre install execution. > That these scripts exists has a reason and the reason is not that > the package maintainers like to add some strange scripts to make > their packages look cool. > > For example somebody doing QA work recently noticed that we've left > an /etc/lyxrc file on the system with the 1.4.x->1.5.x upgrade which > should not happen. So we're now cleaning up behind us with a maintainer > script which is of course bound to special versions. You'll break if > you install your current package an try to upgrade it at a later point > to a Debian version again. In this case it's only an unused old file > but it could of course be anything more important. So how about a recommendation that users when installing a checkinstall binary should uses the following command line: sudo dpkg -r lyx && sudo dpkg -i lyx_1.5.3-1_i386_etch.deb && sudo apt-get -f install > bc) Dependencies don't exist for fun. See above. > bd) i386? And where is the rest? Yep that would be good, but to make it clear, this is an instrumental move. I'm not a developer or maintainer; I am a social scientist, who uses LyX on a daily basis on computers that happen to be i386. For the benefit of others, I am providing my own compiled binaries, for others who don't have the knowledge or the resources to compile the source themselves. > At least I don't see any benefit in the checkinstall crap Checkinstall is a very safe way to install your own complied source, for the very reason that you can remove it in a simple and safe way, which is important as you rightly pointed out. If you choose to install someone else binary relates back to the point of trust. > I might be one of the rare cases of users who used one installation for > seven years with several hardware changes. If you'd like to reinstall > a clean system with every stable release of your distribution of choice > go ahead and use broken packages. Impressive -- this deserves applause! Don't get my wrong, your concerns are valid, but there are many pragmatic and practical reason as to why people compile their own software rather than waiting for a backport or using a rather old version of it. Perhaps this has shed more light on the issues of user-built packages, in general and debian in specific. What do other people think? Cheers, Sam
