On Thu, Jan 17, 2008 at 10:26:48PM +0000, Sam Lewis wrote: > Sven Hoexter <[EMAIL PROTECTED]> writes:
Moin Sam, > > a) The social/trust problem [...] > What solution could you think of? Does the development team use key? Well the Debian project has a known web of trust based on key exchange and extensive peer review of packages. Since you don't have source packages there is nothing to review. That's again a pro of the backports.org infrastructure where you've clean build enviroments supported by trusted people and signed binary packages. That's something you can't even provide without proper packaging. But in the end the trust thing is a personal decision to be made by everyone on their own. > > 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). Not really. The examples are Debian specific (well and in this case Ubuntu specific aswell because they use the same packages) but the problems can occure within any other system with package management aswell. > > ba) You're breaking the upgrade path. [...] > 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 And then there is the user who doesn't remember what he did in good faith to his system. A year later he upgrades to the next stable releases und this fscking update broke his nice LyX installation working for fine for the last year. So who's responsible for the non working package? Must be the Debian guys who just prepared the new stable release which seems to ship a broken package. It's hard to make sure that everyone is able to track such subtle changes he doesn't completly understand and it's hard for the developers on the other side to find out what happened. The frontend tools like apt-get where implemented to ease the system management for everyone but they can not work if you install bogus packages. > > bb) Maintainer scripts have a reason > > 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 Here you missed the point. The error (actually an error we made in the Debian package) is in the 1.4.x packages and will be resolved with a maintainer script in the latest revision of the 1.5.x package. In this special case the file will be left on the system even if you purge the package. So your proposed fiddling won't solve anything. Additionaly it won't solve the latex-beamer issue but it won't cause bigger problems because you're installing into /usr/local. At least I hope that it won't cause trouble but I didn't test if it would confuse latex in anyway or not. > > bc) Dependencies don't exist for fun. > > See above. The toolchain with dpkg and apt were build to resolve the dependencies for you and you're ignoring that part completly. Installing the checkinstall package you can even remove latex (maybe some clean up mechanism even suggest to remove them because they look unused now) without anything complaining. > > Bds......) 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. I might count that in as the only small benefit. > > 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. What I don't get is why you waste your time with this broken checkinstall crap? It's only a very small step you've to make to get the source package and create a backport. The Debian source packages are free for everyone to use (that's essentialy what Ubuntu and other distributions are based upon). The prefered solution for Debian would be to find a DD willing to sponsor the backports.org uploads. Per has no time and interested in the backports stuff and I'm not a DD yet. I guess something similar would be needed for Ubuntu backports but I'm not involved there. It seems that they've a few more releases in work which should be supported with backports but that's a manpower issue. So please use the source packages and build proper backports instead of punching your package management system right in the face! Thanks for considering. Sven -- If God passed a mic to me to speak I'd say stay in bed, world Sleep in peace [The Cardigans - 03:45: No sleep]
