> Slackware - the policy in package management is no policy. > So you can roll out your own tarball. Just be mindful of the > software's dependencies (and watch out also what compiler was > used in compiling the package - especially with developer > packages such as compilers and libraries - you may end up with > ABI-incompatible stufff -> leaving those packages quite useless > lest you roll out another or find a compatible one). Same > checks would have to be considered especially with > contributed packages (not officially endorsed by your distro).
Something to think about... haven't experimented much with installing new versions of gcc, binutils and friends. Hideously complex and frankly, its potential to screw up things big time and require a full reinstall of a production system scares me. Maybe in a couple more years... > Then again it isn't always wise to ignore them. You can get > away with installing a slackware tgz without minding the > dependencies You do have to mind 'dependencies', but not the distro-enforced ones. The 'dependencies' that you have to mind are the ones that the software itself requires and nothing else (always mentioned in the README). And these are not dependencies in the package system sense, just in the common everyday sense (i.e. Freetype 2.2 requires version 4.x and above of svgalib - hypothetical scenario - to be present) It is easy to see whether you have these or not by looking up the packages in /var/adm/packages. If you don't have them, then just download the vanilla tar.gz straight from the source, make your own tarball and install it. If you make a mistake then it can easily be undone by a: removepkg pkg If you change your mind yet again... or you find it turns out another package does require the one you just uninstalled, then a simple: installpkg pkg.tgz is all you need to reverse the consequences. With a dependency tree it's virtually impossible to just uninstall a single package cleanly. For example, and this is one thing about RH that REALLY gets my goat, if you want to upgrade v3.1 of something to v3.2 and the dependency tree happens to enforce the minor versioning (which it usually does) and there are many packages that depend on it...... ARRRRGGGGGHHHHH!! Hair-tearing time... In Slackware, you just assume that all apps that depend on v3.1 can work nicely with v3.2 (which is usually the case, with only minor bugs getting in the way at times, bugs which need to be reported to the respective authors anyway) if you later find out that Package XYZ breaks so badly as to be unusable (quite rare) with v3.b of your new package, it's a very simple matter of doing a: removepkg pkg-3.2 installpkg pkg-3.1.tgz to get things working again. It is a VERY good idea to indicate a package's requirements in the tarball description. The ones that come with Slackware have them and they usually aren't as complicated as you may think. Most are simple enough to keep track of in your head. And if you plan to tweak the source of the app, you should understand the prerequisites tree by heart anyway. _The versioning scheme authors use for their packages is there *exactly* so we don't have to engage in extraneous actions like dependency checking_. Stick to the same major version and things should be transparent. Dependency checking is a roundabout way of saying that it's ok for us not to ensure an author's versioning scheme lives up to its promise, we'll just do a very elaborate dance to get around it. It constrains you to ensure that if you use package abc-3.2 you will need to exactly have package xyz-1.1.0 which is further assumed to only work with package qqq-0.3. The moment you upgrade to qqq-0.4, you break xyz-1.1.0's dependency plus all other dependencies on it (and in the case of a basic package that's A LOT!). It may still work flawlessly (usually better), but you have the added burden of updating the dependency tree. I can imagine automated tools taking care of this dependency update propagation. But then, when it turns out that qqq-0.4 is not so good a release and you have to unroll the dependency updates, all that so-called automation turns out to be a lot of hot air after all! In reality, really complex software like gcc, upon which a lot of other packages depend on, finds it very hard to completely live up to the compatibility promises that its version number implies and that's what led to the idea of dependencies. Unfortunately, it's not a have-your-cake and eat-it-too solution, it's more a 'Rube Goldberg'-type one that, in my experience, creates more headaches than it alleviates. > When I was still using Debian Potato, slackware packages were > quite a blessing for me as I can roll updated software in > /usr/local then play with it [after satisfying the needed > dependencies - if the software requires it]. However, unless > you'll stick with that version for the rest of your computing > life, you'll want to somehow update/upgrade. Then the lack > of policy (or even breaking it) becomes a real pain. You'll > be forced to retrace what packages you installed, then use more > braincycles to figure out how to get rid of them without > breaking other software. Unless you practice proper accounting > of software (which I think a Slackware user should diligently > practice), it will really be a pain. Lazy old me just does an ls -lrt in /var/adm/packages to list the installed packages in order of install date. That's usually the most important thing you need to know about what went on in the past. _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
