LWN.net Logo

Advertisement

Front, Kernel, Security, Distributions, Development. See your byline here on LWN.net.

Advertise here

An apt-get primer (NewsForge)

NewsForge has posted a detailed introduction to apt-get. "If you know how Debian's archive system works, and how to choose the sources that apt-get uses, and use a few precautions in your upgrades, then the chances are that dependency problems will never bedevil you."
(Log in to post comments)

An apt-get primer (NewsForge)

Posted Dec 9, 2004 18:26 UTC (Thu) by elanthis (guest, #6227) [Link]

"If you know how Debian's archive system works, and how to choose the sources that apt-get uses, and use a few precautions in your upgrades, then the chances are that dependency problems will never bedevil you."

In other words:
- If you know how to use the tools,
- And you know to only pick safe tested sources,
- And you don't do anything stupid
Then you won't have dependency problems.

Wow, sounds just like any other packaging system... ;-)

Seriously, apt does not get rid of packaging screw-ups. dpkg does not make them anywhere near impossible. You just rarely see conflicts because Debian centralizes almost all packaging efforts and has a good, solid standards document on how to do the packaging.

The standards document is the important part. If RPM based distros wrote and stuck to a standards document there'd be just as few package conflicts in the RPM world. And if you find a dpkg that doesn't follow the Debian standards, then it'll likely have broken dependencies as well.

Unfortunately, I don't believe that centralization, as Debian does, is really a good thing. No matter how many volunteers you have (and in fact, there is a point when you have too many) you will never package every piece of software every user wants, and you'll never have the latest version that every user wants.

If you want a good system, you have to focus far more on the standards and policies for packaging. If you do so, and only compliant packages are used, your packaging system will work just as well with completely decentralized package sources as with several central sources.

An apt-get primer (NewsForge)

Posted Dec 9, 2004 20:42 UTC (Thu) by ballombe (subscriber, #9523) [Link]

"If you want a good system, you have to focus far more on the standards and policies for packaging. If you do so, and only compliant packages are used, your packaging system will work just as well with completely decentralized package sources as with several central sources."

To avoid the dependency hell, you have to make sure everyone use
the same version of each packages at the same time so that noone
provide packages depending on version incompatible with the one
you have.

How are you going to enforce that without a centralized registry?

An apt-get primer (NewsForge)

Posted Dec 9, 2004 21:04 UTC (Thu) by iabervon (subscriber, #722) [Link]

Actually, you just have to make sure that each different version of a package is either backwards compatible with previous versions or may be installed concurrently, which means that each package must be handled carefully, but centralized control is not needed.

An apt-get primer (NewsForge)

Posted Dec 9, 2004 21:10 UTC (Thu) by TwoTimeGrime (guest, #11688) [Link]

> To avoid the dependency hell, you have to make sure everyone use
> the same version of each packages at the same time so that noone
> provide packages depending on version incompatible with the one
> you have.

That's the kind of assumpsion that leads to bad packages. When you specify a dependency in a package you don't have to specify a specific version. You can say:

1. This package requires foo
2. This package requires foo >= 1.4.2
3. This package requires foo == 1.4.2

Some of the problems with packages out there is that people will specifiy a specific dependency such as foo == 1.4.2 when any version of foo would have worked. It takes work on the part of the packager to make sure that he specifies the least restrictive dependency that will still allow the program to work.

compnentized linux

Posted Dec 9, 2004 21:56 UTC (Thu) by penguinwarrior (guest, #20672) [Link]

not sure, but the whole version thing with dependencies is trying (if i got it right) to be worked out by ian murdock et al. at progeny with their componentized linux

www.componentizedlinux.org

their making it that if you want say kde, all dependencies will be resolved by downloading it as a 'component' in which all needed packages are downloaded. again, if i have it right, you could have kde 3.0, 3.1, 3.2 installed at same time without pinning as long as you have your sources correct.

actually, i'm using it because the install uses anaconda, and is sweet. the first 2.6 kernel install where my modem is detected without problems that i have tried (even mepis, which i also like).

An apt-get primer (NewsForge)

Posted Dec 10, 2004 14:57 UTC (Fri) by jamesh (subscriber, #1159) [Link]

By "same version of each package", I think the ballombe was referring to different ways of packaging the same upstream package, rather than handling packages for multiple upstream versions.

Consider the case of Fedora and SUSE packaging the foobar-0.42 package. Some things they could do differently include:

  • If it is a C++ library, they could compile it with different C++ compilers, and end up depending on different C++ standard libraries. This causes problems for packages using the library, especially if they need to use some other C++ library too.
  • If the upstream package is split into multiple binary packages, two different packagers might split it in different ways.
  • Different names could be chosen for the binary packages.

All these issues would affect dependent packages, and is what people usually talk about RPM dependency hell. It isn't clear whether dpkg would handle the problem any better if a new distro popped up that didn't follow Debian's packaging guidelines.

Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds