|
 |
| Thu, Jan 08th | home | browse | articles | contact | chat | submit | faq | newsletter | about | stats | scoop | 20:12 UTC |
|
|
login « register « recover password « |
|
|
|
Mirrors are extremely useful when used to their full potential -- but this rarely happens. There is nothing wrong with mirrors but the way that we use them. I want to make it so average users who don't (and shouldn't need to) know too many technical details can automatically make the best use of mirrors. [Comments are disabled]
The GnuCash installation instructions warn non-programmers against even trying to install it. The word "nightmare" is used. Ideally, the process should be quite simple. If the project were distributed using Zero Install, users could safely fetch and run it, with all its required dependencies, using a single command. [Comments are disabled]
This article records our experiences with packaging an application for many distributions and shows areas in which packagers, Linux distributions, and developers can improve coordination for better and easier distribution. We look at communication problems, packaging errors, package dependencies, menu entries, and bug tracking systems. [Comments are disabled]
Any veteran GNU/Linux user has, at one point or another, run across a package which used the autoconf/automake toolset. There is a lot to be said in favor of this emerging standard. Running "./configure && make && make install" usually results in a working installation of whatever package you are attempting to compile. The autoconf tools are also portable to almost every *nix platform in existence, which generally makes it easier to release your program for a large variety of systems. However, despite these few pluses, the auto* tools are constantly a thorn in the side of users and developers alike. [Comments are disabled]
A more defined process is needed for development, distribution, and deployment of software. Specifically, we need to revise the current process which makes the end product of software development an archive file (gzipped tarball, Debian package, zip file, etc.) which is distributed on a CDROM or downloaded through the Internet via FTP or the Web and finally installed and configured. Software development, distribution, and deployment is a group activity carried out through collaboration over the Internet; it should include application developers, component developers, software users, and software testers, auditors, and reviewers, among others. [Comments are disabled]
The Unix98 standard requires largefile support, and many of the latest operating systems provide it. However, some systems still chose not to make it the default, resulting in two models: Some parts of the system use the traditional 32bit off_t, while others are compiled with a largefile 64bit off_t. Mixing libraries and plugins is not a good idea. [Comments are disabled]
Most software packages need to install a large number of files to work -- binaries, images, documentation, etc. Until now, this has been done by providing an install script (possibly in a Makefile or an RPM spec file) which puts each file in its correct location. If you're lucky, there may also be an uninstaller to get rid of them again. Both must be run as root, which is awkward and has security issues. In this article, I present an alternative system. [Comments are disabled]
Recent freshmeat editorials have dealt with the current state of package management systems. Today, Alex Botero-Lowry and David Eklund look to the future and discuss the work they're doing to create an alternative that draws on the best features of the current "big two". [Comments are disabled]
In a followup to Claudio Matsuoka's "Is it Time to Change RPM?", Alfredo Kojima offers news of Conectiva's APT/RPM integration work, gives the reasons he thinks it's superior to other RPM frontends, and hopes it will provide a means for bringing the various Linux distributions closer together. [Comments are disabled]
New Linux distributions usually base their package management on one of two options -- Red Hat's or Debian's. Brazilian distributor Conectiva decided to go with RPM, but has reservations about its ability to provide smooth automated upgrades. In today's editorial, Conectiva's Claudio Matsuoka describes the problems he sees and what he thinks should be done. [Comments are disabled]
Dave Gudeman writes: "A developer who wants to make a piece of software available to others faces the daunting task of software delivery. There are several strategies for delivering software, primarily source code, machine binaries, and virtual machine binaries, each with its own advantages and disadvantages. I'm going to discuss each of the alternatives, then suggest a variation that is potentially better than any of the other solutions for commercial as well as Open Source software projects." [Comments are disabled]
Bud Bruegger writes: "This paper discusses the need for extending the philosophy of GNU autoconf into the world of package management. Such an extension could be seen as a 'universal source package' standard and tools. It was written with the hope of stimulating a discussion on the feasibility of such an approach." [Comments are disabled]
|
|
