Re: kde 4.3.4 is building for unstable now ;-)
Alle domenica 13 dicembre 2009, jedd ha scritto:
> On Sunday 13 December 2009 20:18:39 Valerio Passini wrote:
> > Ok Jedd, do everything your own way, but let me underscore that you
> > are quite often complaining about the way KDE doesn't work for you
> > and reporting numerous malfunctions in your system that none else
> > is experiencing. Maybe that following your own way is causing some
> > troubles? If I was you, I would consider this possibility. I hope
> > you understand that mine is just a fair critics. Bye
>
> Hey Valerio ... I feel I might be about to 'protest too much' :)
>
> I accept that many of my posts are a bit complainy in nature,
> but I dispute that (m)any of them could be tracked back to a
> self-compiled kernel or self-compiled nvidia driver.
>
> I accept that some people think that one or two of the bugs
> I've asked about on here are related to the nvidia driver per se,
> specifically the delay while resizing one application (konsole).
>
> I've pointed out already that my earlier message in this thread,
> regarding snow on the screen, turned out to be due to the mix
> of 4.2.4 and 4.2.2 packages. It was posted more as a warning
> to others to delay updating their unstable box for a few hours.
>
> I should probably have been more explicit about that, I suppose,
> but I appreciate when others post such recommendations, as it can
> save you a whole heap of pain.
>
> Looking at the output of make-kpkg, specifically the kernel image
> and the nvidia drivers - they (as you'd expect) come out to be
> binary-identical files, no matter what packaging method you use.
>
> (This makes sense because for the kernel, I'm using the Debian
> kernel source packages, and for the nvidia driver, we'll we're all
> using the same file from the nvidia site.)
>
> That is, native nvidia installer, or Debian wrapper around same -
> will both produce identical kernel and xorg modules. As I say, this
> is exactly what you'd expect. Similarly, a 'make bzImage && make
> modules && make modules_install' will produce an identical set of
> binaries in /boot and /lib/modules as using make-kpkg and then doing
> a dpkg --install on the resultant .deb would. Again, as you'd
> expect. If there *were* any differences, then I'd be very worried.
>
You were right if you didn't forget about APT.
You are lucky because Debian doesn't introduce too much differences in
the paths of libraries, executables and so on, at least on fundamental
stuff like the kernel this allows you to mix source code compiled from
tarballs and binaries belonging to the Debian repositories. Anyhow, even
if you have the same library/executable and path, apt cannot track the
stuff you compiled and installed using "make". This is the main reason
why using .deb is strongly recommended everywhere unless you have
special needs or you want a software that is not yet packaged.
> I doubt you're suggest that there's some kind of weird homeopathic
> 'memory of the command line that made it' influencing factor such
> that a kernel knows whether it was made with make bzImage or
> via make-kpkg. If it does know this, *and* behaves differently,
> then that's very bad news for all the RH, CentOS, Suse (etc) users.
> :)
No weird belief in "PC mistery" here. I'm just suggesting: 1) you are
probably screwing your system and fooling apt; 2) you are missing all
the good features that a debianized kernel has, like calling update-grub
at the end of the installation process automatically or not to have to
go inside /lib/modules/ and use "rm" to remove stuff when you want to
purge a kernel or having the chance to compile and install external
modules from m-a.
The proof that the two methods (debs and compiled sources) are not
exactly the same is in the fact that every time Xorg is upgraded, you
_need_ to rerun nvidia-installer. Why? Because apt removed links and
files from the nvidia drivers during the upgrade. On the opposite, this
doesn't happen to those which use m-a. This is the reason why I have
completely abandoned the "make this and that" workflow and I have
embraced make-kpkg and m-a: it's simply superior.
Try it.
Valerio
Reply to: