Slashdot Mirror
APT - With Your Favorite Distribution
Then there is another solution from Connectiva in Brazil, which has made something called APT4RPM -- basically an APT wrapper around RPM database on your machines, so you can use all of Debian's APT features (sans DSELECT feature) to upgrade your packages, or your entire distribution. (So now you can use your favorite distribution AND APT to update it.)
Two open source developers have improved Connectiva's solution to work with ANY RPM-4 based solution, and the [not finished yet but seems pretty stable solution] is at APT4RPM project pages in sourceforge. I have decided to give a test on my Redhat 7.2 machine. I installed the binaries, edited the /etc/apt/sources.list (just remove the # from your distribution's mirror), typed "apt-get dist-update," crossed my fingers -- and lo and behold, 48 new packages were installed, 7 were upgraded, and I only had to press "enter" to start the ball rolling!
So, for those of you who want to test it -- the URL is above (and if you could help with creating mirrors for your favorite distribution - that would be very helpful, thank you), you might want to try it. Just don't forget to read the FAQ before doing anything, and report bugs to the authors. Note: although the binaries are for Red Hat, the SRPMS are right there so you can just recompile it on your favorite distribution. Enjoy.
For apt to work to it's full potential you need a have a list of all available packages at the time in the current archive. Which debian has, so the question is how many of the other distros are doing this to make sure all the dependencies are currently in check? Cos I can see a lot of conficts to be had if there isn't one or isn't done properly.
*shrug*
It would be great if they had something like a P2P scheme for patches, and new modules. Imagine if even 25% of Linux users took part in it. Always-available high speed files of any type you need.
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
Debian/unstable is where new packages go. Here, packages are often built right from CVS. Yes, if you track Debian/unstable, you might get burnt every now and then from bugs. But on the whole, it's very good; everything is up to date, and it's about as stable and bug-free as a Red Hat
Debian/stable is almost totally static. The only reasons a package in Debian/stable is updated is for security reasons. Even then, usually, the fix will be backported to the version of the app that's in Debian/stable. For instance, if a long-present security bug is fixed in BIND 9.2.0, but Debian/stable asdlfkjasdglakjsdf, then the fix will be backported to that version; the package won't be upgraded right to 9.2.0. Why do this? "Stable" doesn't just mean apps that don't crash. It also means a common platform. Debian/stable will change only very, very rarely. This makes it an ideal target for sysadmins who wish to use trusted software, and for developers who want to target the lowest common denominator.
Yes, all three Debian trees use apt-get; in fact, moving from Debian/stable to Debian/testing is a matter of two or three commands, usually(ditto for Debian/stable -> Debian/unstable, or Debian/testing -> Debian/unstable). Almost all Debian mirrors have all packages from all trees in all supported architectures.
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Add to your list of communities with offensive users LISP and some parts of Java. I can't stand to read Java books that denounce other programmers and other technolgies, and too many of the LISP books I have read do the same.
Why can't they let the merits speak for themselves? Bashing others just turns users away - users like me who don't care for the politics.
Use a script or scripts -- keep an up to date
list of the ftp-accessible RPM
resources for your distribution. Use --test
with rpm -Uvh and when you have a
dependancy -- just grep your list(s) and
wget anything you need. In all, it keeps you on top of
what is going on with your system.
Not hell at all, IMHO.
I will share the scripts I use for mandrake if anyone wants them.
#netselect-apt unstable; apt-get update ; apt-get -yd dist-upgrade ; apt-get dist-upgrade
Actually, probably replace those semicolons with && so commands proceed only if everything is ok.
It's a good time to be a Debian user :-)
I know I will most likely be marked down for this, however.........its a flaw in open source.
You CAN'T do dependency checks accurately. Sure, with Windows you can check for the latest version of microsoft runtime libraries.......but, its easier........Microsoft is a closed-source system........they control the binary compilations......
For this reason alone, Microsoft and closed-source has a much EASIER time being used by the masses. Sure, you still get version conflicts, but I have not had one that I can remember in the last two years. Installers have now started checking version numbers, and they are getting smarter.
Linux will never get to this point while users are given the option of downloading binaries that may contain pre-compiled libraries from the application's developer........they could be a much older version, or some incompatibilities introduced.......but how would the system check??
The only solution I could see is a smart-dependancy checker that is able to get a list of specifications on the functions, and verify that each is there and working properly....and I don't see that happening.
www.atacomm.com - The Leader in VoIP Product Distributi
My approach to making a package format is running 'ldd' on every executable and then recording the dependencies, within the package. Any extra binary packages required (for eg. progs exec'ed from the application) can be entered by the user at the time of building the package.
./configure'ing it from source. I'd prefer an equivalent mechanism adapted into making a package and figuring out its dependencies.
This way, the package dependencies can be as trustworthy as
I've been a long time slackware user, and i'm so in love with autoconf/automake that i wish someone extended them to binary packages as well.
Sometimes, you're just not in a mood to compile the stuff up from source. I wish someone makes something out of this idea of mine.
Nikhil.
The biggest problem with dependencies in RPM's is that there is a lot of human interaction required. I've seen A LOT of packages that require one of the following, thus causing a problem :
In each of these cases you have a problem. If I have Sendmail 10 installed and I'm installing an RPM that wants Sendmail 9, while I satisfy the requirements, it won't install. I'm not sure how debian deals with this.
If I have Exim installed, and I'm installing a package that wants Sendmail it won't install. Debian packages generally want MTA, a requirement which is satisfied by either Sendmail or Exim (or postfix for that matter).
If a package just wants a library without saying what package it comes from, apt is NEVER going to know what to install to satisfy that dependency without maintaining an Index of the contents of all packages.
These are deficiencies in the packages created by the package maintainers. There are other problems with the actual RPM way of doing things which are further compounded by the distribution builders.
A standard Mandrake install has about 30 packages as required that I have NEVER used. They are only required for certain circumstances, most of which I never needed. But I have to have that clutter lying around my system.
RPM is broken at 3 layers IMHO. The distribution builders, the package maintainers and the design of the application. Wrapping all of this in APT isn't going to solve anything. But until a viable alternative is marketted by someone with the power to drive it, RPM will remain the industry standard for commercially targetted GNU/Linux distributions.
Personally, I use FreeBSD and I love the make world solution for the base distribution and the ports solution for packages. This keeps me current, makes sure that all binaries are optimised to my processor and provides me with a one stop upgrade point. No hassles, no dependency woes and more time to get on with my job.
try gentoo linux http://www.gentoo.org It takes care of dependencies and is very up to date with packages. It even supports safe uninstalling of packages. Like ports only better.
would be an RPM upload checker...
When you create an RPM, and upload it to a central depository, the checker would verify that the dependencies your package points to, exist there.
If you have perl21 alpha on your system, but perl 6 is the only version released as an RPM for a distro, then either make a perl21 RPM and upload that as well, or change the dependency to perl6, and see if your software still works.
If distros chose to keep 3 branches of development, they could be renamed.
stable
installable, and
advanced
If a proposed package did not have all of its dependencies in stable and installable, it could not go into either of these upload trees.
Completely automated package management could be made on a system that installs proposed packages, either on a pure system maintained by a maintainer, or in the chaotic user space, where through feedback of the installer, users could report back whether the package actually worked with the claimed dependencies. Automated user feedback systems could decide what goes into stable. Dependency trees could list all of the alternative versions of a single dependency which work, not because the author or maintainer have tested all versions, but automated user feedback has determined what works.
Trolls/hackers who intentionally falsify claims of operation could have an impact, but if there are 2 claims of the same configuration. One works the other doesn't, there is likely a way for it to work with that configuration.
FreeBSD's ports collection minimizes this problem by being one coherent unit. I very rarely find a dependency that isn't automatically downloaded for me when installing a new port. The only downside is that it takes a while for the latest Linux applications to get into the Ports collection. If its something really popular, it gets ported pretry quickly.
I have to disagree with you here. I use inst & co. quite a lot (I admin a number of irix machines) and have very little good to say about it. It's may be a bit better than some others, but compared to apt/dpkg *or* rpm it's woefully inadequate. It's always a relief, after installing an irix box and weeding out the hundreds of unecessary fluf packages in the default install, to go back to one of my debian machines.
Version dependancies, for example, can be extremely confusing. If you have the wrong version of some eoe.* package for a package you want to install, it can be very difficult to parse the version info and jump through the necessary hoops to get what you want in place.
My biggest problem with inst, though, is that there is no effective way to deal with large numbers of packages. Sure, there are various keywords you can use, and they help, but they're basicaly a hack. Going through an extensive list (e.g., the freeware distribution, or even worse, the default install) and trying to prune out the stuff you don't want and/or put in the stuff you do want can be extremely unpleasant. I generaly find I have to make a large list, on paper, of the often literaly hundreds of package additions/removals, then use inst to implement them.
So we have: 5467 source packges (8558 binaries), and 934 registred maintainers. I.e. 6 sources, or 9 binary packs/maintainer, rather than 1-2. Still not bad, though.
First 21 maintainer takes care of 30 sources packages or more, for a total of maybe 1000 (sources) packs. 144 maintainers care about >=10 source packs etc.
Now let's go and look at the bottom of the list:
270 maintainers with 1 pack
141 maintainer with 2 packs
...
While this is a great thing to have, the fact remains that it's the "top 50", or maybe "top 100" who make the most of the stuff, and each of these has a fair number of packs to do. Not that much different from commercial distros.
make
make install
Uninstallation just involves removing the directory. This way I don't need to keep the source lying around and it's easy to change which version of the software I want to use. I usually do a
ln -s /usr/local/emacs-21.1 /usr/local/emacs
so I don't need to update my PATH every time I compile a new version.
The only downsides are that /usr/local gets pretty cluttered and PATH sure gets long, but it's worth it to me.
Unfortunately the solution is not open-source/gnu/whatever your fav. term is, friendly. With RH, Soose, SnackWare, YD, or whomever, in control, how can a regly joe developer fix a packaging bug? A bug in the code, yes, post your patches, etc. But packaging is a meta-data thing that is mostly immune to the usual bug fixing process. It is the delivery of the code, not the code itself, so its 'above the law' in a sense that the code itself is not. Sure, I could take a distro and just fix the prereqs or other packaging stupidity, but:
I cannot install a fix to buggy/stupid package delivered to me on a CD. Once it ships, its a done deal. Which means getting packaging right the first time is even more important (though often undervalued and underappreciated). Electronic distros can be fixed more easily, but releasing a new copy of a package with the same version is bad juju, and how many folk wanna upgrade versions just to get a fixed package which they've already managed to get installed?