 |
 |
 |
 |
 |
 |
 |
|
|
2005-02-22 - Stuart WinterSlackwareAn interview conducted by FOSDEM & the LinuxFR readersFOSDEM - First and traditional question: please present yourself ! Stuart Winter - My name is Stuart Winter. I'm 24 years old and am living and working in Surrey, UK. For the past year or so, my main computing hobby project has been my unofficial port of Slackware to the ARM architecture. I also developed and maintain a package building utility, 'slacktrack' which helps produce Slackware-compliant packages from simple build scripts. FOSDEM - How and why did you start with working on Slackware ? Stuart Winter - Before I went to university, I asked a friend whether I could have a POP account in which could store tonnes of email (as I didn't know how often I could check it). I soon found out that my POP account was actually a shell account on a Slackware box, so I started poking around. The installation felt "clean", precise; the config files were extremely well documented because Slackware is a hands on distribution. I got myself a copy of Slackware 3.5 from a University CDROM called "Burks" or something similar. Within two weeks of using Slackware, I'd started to make real headway with learning Linux. I've stuck with Slackware ever since then. I don't work on Slackware in the typical sense, I do contribute fixes and suggestions in the same way as many others in the community. I'm not sure when I first contributed something substantial -- it was possibly the adduser script. The original script was very basic and didn't do any error checking, so I asked Patrick if he'd like a new version that did. FOSDEM - slackware packaging system is one of the oldest one. What are its limitations due to that ? And, if so, what are its advantages ? Stuart Winter - One of beauties of Slackware's packaging system is that its feature set is so minimal yet so effective. The package files are gzipped tar archives making it easy to view the contents of packages using standard tools available in all Linux distributions. The system package database and package setup scripts are a collection of ASCII text files, allowing simple shell scripts to be created that can query and amend all stored information of an installed package. I used to build Slackware packages of a number of applications, and one of the things I would have found most useful would have been pre-installation and post-removal scripts (Slackware only supports post install scripts) to remove old config files and perform some final janitorial work. If you compare and contrast Slackware's package and package management system against Debian's and RPM for example, there are a great many features that, *by design*, are noticably absent from Slackware's; and for me personally I can't say that I miss them! FOSDEM - what do you think about source-based distro like gentoo ? As computing time is costing less and less, wouldn't it be better to compile on the fly ? Stuart Winter - I think source based distributions such as Gentoo are great for the community. People find incompatabilities between packages (for example, some software needs updates to build against more recent gcc versions, automake versions and so on), leading to build failures. These failures get reported and the bugs get fixed -- everybody benefits (even more so if the fixes are pushed upstream). I take build fix patches from gentoo sometimes :-) However, I prefer to think that the binary packages I'm installing are production ready -- they have been tried and tested. For example, I found that I'd built a duff glibc for ARMedslack. The logs didn't indicate any failures, the checks passed, but still when I booted the dev box, the new glibc caused the system to hang; it turned out to be a specific version of gcc that caused the problem. It also depends on how fast your machine is and what its purpose is. I wouldn't want one of my production servers constantly building new packages -- I want to install the binary security fixes and updates, leaving the machine to serve its intended purpose. Infact, on the production machines I manage, we don't even have any toolchains installed! FOSDEM - are there any plans on changing slackware's packaging system, like dependencies checking, ... ? Stuart Winter - No. Slackware's minimalistic approach (including the lack of dependency checking) is a deliberate design choice. The packaging system tools are mature and well tested in their current incarnation, thus Patrick is always highly reluctant to make any major changes. There are a number of third party package managers which sit on top of the standard Slackware package tools and help aid with issues such as dependency resolution. Some of these package managers also cater for additional metadata, allowing the package author to dictate specific version numbers of packages on which their package depends (as you find most main stream package systems). However, Slackware's official tools do not support these 3rd party additions and there are no plans to do so in the future. With regards to dependencies in particular, may I quote Patrick: "The design approach for Slackware is to ship a cohesive system where a full installation of all the packages is recommended. If this is done, there will never be any dependency issues. After shipping a new release, if patch packages need to be shipped that is done in such a way that if you keep up with all the patches you will not have dependency issues with any of them either." If you followed the recommended approach then the only dependency issues should be with 3rd party packages. FOSDEM - don't you think that a "common" packaging project should be initiated to "standardize" Linux distributions packaging, so that every (or at least most of them) distributions could benefit from it? Stuart Winter - If I look out of the window of my aeroplane and see each Linux distribution from way up high, I'd probably be inclined to say "yes" to the above question. However, as soon as I get on the ground and start looking around, I see that it just doesn't work like that. Package maintaners and distributions have different policies, cater for different needs and tailor the packages to suit. In an world where every distribution used the same versions of libraries; compiled with the same features; had an identical file system directory structure; used the same package build system and distributed the binaries in the same format, then such a system may be feasible to some degree. I can see the benefits of such a project but I don't see how it could possibly be successful in reality. FOSDEM - beside packaging, there are also "installation" tools, like swaret ... do you think such tools can make things smoother for end-users ? Stuart Winter - Slackware was never designed to accomodate such automation, therefore these tools don't always work as one would hope (and if you're tracking Slackware-current, possess the potential to do more harm than good; you should always read the ChangeLog.txt notes before upgrading a package!). You may notice that in the latest release of Slackware, there are no 3rd party package managers that handle dependency resolution. Personally, for my development machines I never use anything but a few home grown scripts that wrap around upgradepkg, and for my servers, desktop and laptop I do the updates manually (although I confess that the manual element doesn't scale well, I like to put in some time to take care of my systems by hand) which is by far the safest and most tested way of maintaining a Slackware system. However, many users do enjoy success when using swaret, slapt-get et al; these tools can ease the burden of keeping your system up to date, and definitley have their place within the community. FOSDEM - What do you expect from your FOSDEM talk? Stuart Winter - I hope to spread some knowledge and meet fellow Slackware users and contributors. I hear that Belgium has some good beer too :-)
|
|
|
|
 |
©
FOSDEM 2003-2005 - powered by Argon7 |