How to check why 'CheckInstall' is no longer available in 'Testing' ?

Akhran · 03-13-2006, 01:34 AM

Checkinstall is still available in 'Stable' and 'Unstable' but no longer in 'Testing'. Is there a way to find out why it is missing from 'Testing' or when it would be made available?

Thanks!

nx5000 · 03-13-2006, 03:33 AM

Quote:

Originally Posted by Akhran

Is there a way to find out why it is missing from 'Testing'

Maybe here:
http://ftp-master.debian.org/testing...e_excuses.html

Quote:

or when it would be made available?

I guess *not before* these things are corrected

Akhran · 03-13-2006, 08:51 AM

What does the following mean?

# checkinstall (- to 1.5.3-3)

* Maintainer: Matt Hope
* 699 days old (needed 10 days)
* Ignoring medium urgency setting for NEW package
* checkinstall (source, i386, alpha, ia64, mips, mipsel, powerpc, hppa, arm, m68k, s390, sparc) is buggy! (4 > 0)
* Not considered

Thanks

Quote:

Originally Posted by nx5000

Maybe here:
http://ftp-master.debian.org/testing...e_excuses.html

I guess *not before* these things are corrected

rickh · 03-13-2006, 09:16 AM

From the book, The Debian System by Martin F. Krafft:

Quote:

Checkinstall is limited in what it can do. To be precise, the packages it creates can only install files, and checkinstall does not care where it installs them. You can overwrite files in /home directories with checkinstall, among other things. The generated packages can not modify files. If the installation routine modifies existing files, they will be part of the generated package in their entirety.

A horror scenario occurs when an installation routine adds a user by modification of /etc/passwd, which is subsequently included in the package. Installation of the package causes /etc/passwd to be completely replaced, and the deinstallation of the package removes the file, breaking the system in half.

The generated packages also fail to register their configuration files with dpkg, therefore paving the way for upgrades that overwrite local configuration file changes.

In light of these problems, it is probably a good idea to avoid but for the rarest cases.

This was written at least a year or more ago. Obviously, things haven't improved. If you want your package to be included in Debian's system, you can not ignore known problems.

Dracae told you, in another post, how to correctly build Debian packages. In my observation, if Dracae says it, it's gospel. Don't screw with inferior products when the real thing is available.

Akhran · 03-13-2006, 06:04 PM

Would that suggest that installing from source (./configure, make, make install) is not recommended on a debian system?

Thanks

Quote:

Originally Posted by rickh

From the book, The Debian System by Martin F. Krafft:

This was written at least a year or more ago. Obviously, things haven't improved. If you want your package to be included in Debian's system, you can not ignore known problems.

Dracae told you, in another post, how to correctly build Debian packages. In my observation, if Dracae says it, it's gospel. Don't screw with inferior products when the real thing is available.

dracae · 03-13-2006, 06:24 PM

You might as well be using LFS. The thing that makes Debian stand out from the rest, is it's (IMHO) superior package management system. All distro's more or less have the exact same software, it's how they implement and manage them that sets them apart. Why would you want to throw that all away? I personally do not have the time or will to completely manage a system. Things like checkinstall and alien will never find there way on any of my systems. If you absolutely need some application that hasn't already been "debanized", adopt it. It's not difficult to build debian packages from source "The Debian Way". Make it official and contribute to the community by maintaining it. There is a very well written guide available.
http://www.debian.org/doc/maint-guide/