Slashdot Mirror

I keep versioned backups of all my configuration anyway, so this is not a serious issue. (using or not YAST, I strongly recommend you keep versioned backups of your configuration files. Use CVS if you want, but use something. It really worths the pain)

Have a look at etckeeper.

etckeeper is a collection of tools to let /etc be stored in a git, mercurial, darcs, or bzr repository. It hooks into apt (and other package managers including yum and pacman-g2) to automatically commit changes made to /etc during package upgrades. It tracks file metadata that revison control systems do not normally support, but that is important for /etc, such as the permissions of /etc/shadow. It's quite modular and configurable, while also being simple to use if you understand the basics of working with revision control.

Yet another DVCS article that doesn't mention Bazaar at all.

Well, in all fairness, the article is entitled "The Rise of Git".

And I know that performance isn't everything, but for some of us who run git everywhere to track our home dir (see the end of that article) kind of find the performance of git to be pretty nice. Other people have come to similar conclusions.

Now everything is going "cloud", I can see a gap in the market for "family cloud" appliances - plonk them on your home network, trust a few similar units on the networks of family members, and get the benefits of redundant backups, mail service, etc, exchanging the cost of your privacy for a few hundred dollars.

That is exactly what Eben Moglen discussed during his presentation at DebConf10. Info on the presentation (including links to video) is available. Also check out Joey Hess' commentary on the presentation. His objective price point is less than one hundred dollars, IIRC.

Just a shirt? C'mon, you really want to go for the tattoo!

http://joey.kitenet.net/blog/entry/ouch__33__/

He's probably using etckeeper, which is a wrapper that does keep permissions, ownership, and empty directories. It generates the commits automatically on update and daily for manual changes. Yes, I use it too. Very nice to be able to say "oh, looks like I broke the VPN configuration when I forgot to restart it last week... how did it look before?"

I use a constellation of git repositories, and Joey Hess' mr tool to synchronize all of them. I have no automated commits -- I just remember to commit and update manually daily.

Also check out etckeeper, http://joey.kitenet.net/code/etckeeper/ , which works with git, mercurial and bzr. And has nice apt-integration on debian.

ls -1 > /tmp/files
vi /tmp/files # edit list to include just the files I want
rm `cat /tmp/files`

Instead of creating the tempfile, you can use vipe (included in moreutils.)
vipe allows you to "vi" the "pipe", like so:
$ ls -1 | vipe | xargs rm

Fundamentally, a binary package is a set of files to be installed in specific locations. Those specific locations are built into relationships between files, both within packages and between packages. Between packages is an important part of the equation -- it allows the entire system to run a set of shared binary libraries. If every application carried it's own version of gtk or other libraries and didn't share RAM, the modern desktop would be unworkable.

What companies want is a single binary to run on "Linux", the way a single binary runs on "Windows". But it's not just a matter of writing alien, which can convert RPM binary archives into .deb archives. You need binary compatible libraries!

You can, however, use RPMs pretty freely through Alien, which gives you far more options in package selection.

Cool, thanks for the link, although I think I need rather more space than they offer. I'm hoping to do something like keeping an entire home directory in SVN:

http://kitenet.net/~joey/svnhome/

Here's a comparison: http://kitenet.net/~joey/pkg-comp/

Debian packages have several features that make them more useful, especially when it comes to dependencies.

OfflineIMAP would fix most synchronization problems. Dovecot is a fast IMAP server and Maildrop coupled with your favourite smap filter could take care of the server part. Couple that with a good mail client (mutt) and a way to synchronize contacts. mutt can be customized with own keybindings, so that way one could add support for training the mail filter. I keep my home directory in a darcs repository to keep it in sync between machines. Other people use Subversion.

Ikiwiki ( http://ikiwiki.kitenet.net/ ) is a really extendable wiki/blog-software and you could write a plugin in the style of Trac's Syntax Coloring support ( http://trac.edgewall.org/wiki/TracSyntaxColoring )

The connection appeared to hang waiting for the stylesheet, so this was only viewable by viewing the HTML source. Obviously relative links are all busted.

Basically, Dunc is an experimental project to try out ways of funding Debian development. Not paying for servers or bandwidth, or reimbursing expenses and flight costs, but actually paying people to sit down and do useful Debian work rather than some other day job.

There's info about who exactly is behind Dunc at the board page.

Dunc directly supports work on Debian, and is made up of a small group of people who use Debian and who want to see Debian improve. But Dunc is not endorsed by Debian, and Debian does not exercise any control over how Dunc operates.

A number of other groups fund Debian work directly or indirectly, whether that be by allowing or encouraging their employees to contribute to Debian, or having Debian work be part of their actual job description. Dunc does not aim to compete with those groups, either in the tasks being worked on, or in the people being recruited, but rather to address other niches in the Debian ecosystem.

Dunc is an acronym standing for "Development Under Numismatic Control" -- which could equally be called "coin-operated coding". The point of the project is to try some new possibilities of funding free and open source software development and helping people work on free software development on a full-time basis.

Really, though, the name is a reference to the linux.conf.au auction in 2003, for the t-shirt signed by the speakers, proceeds from which were directed to Electronic Frontiers Australia. To make the bidding more lively a certain individual foolishly suggested that the next Debian release would be named after the winning bidder, should the bidding go above $2000. Due to the combined resources of a table of inebriated Sun folks, Duncan Bennet won the bidding, and the right to have his name associated with the next Debian release -- which, many years later, turns out to be Debian 4.0, aka etch. So yes, this is yet another free software project that has its roots in the consumption of a little too much wine at a conference dinner.

As Dunc is an experiment, we don't know what will end up happening with it. We may decide it works perfectly as is, or that it was a horrible idea that should never have been tried. In any event, we expect to review what worked, what didn't, and what should be done over the course of the first project, and have a public discussion about what to do after the release of etch.

This site is maintained using Joey Hess's ikiwiki.

It is licensed under the terms of the GNU General Public License, version 2.

Yeah, right. :)

• the Linus type "have fun and cooperate" and
• the RMS type "OSS is religion"

> What sort of legal advice has Debian consulted that came to a > different opinion? There is a sizable pool of people that regularly examine licenses for Debian, looking for problems. Debian does not regularly consult practicing attorneys on these issues. debian-legal

One has to go through a notorious process to become a developer but it just needs an email client and a subscription to debian-legal in order to strangle 1500 developers. Time to change Debian back from a supermarket thing to one of the leaders of technology. Congrats Anthony!

The kind of canonical article about SVN homedirs is this one: Subverting your homedir. I've got it set up between Mac OS X, Linux, and Windows, and it's pretty awesome.

Another example is here in a LUG's wiki. Also, if you have any questions, I'd be happy to answer questions about my setup.

I broadly agree that RPM and DEB are roughly equivalent. Joey Hess's package format comparison remains one of the better documents on this. While there are a few things RPM handles slightly more cleanly (signed packages), the one clear win to DEBs are the fact that they're unpackable with bog-standard shell tools (ar, tar, gzip) while RPM is a binary format strongly favoring use of a library, though some perl hacks can unpack the format, as will dd given the right offset (varying with versions of RPM). RPM itself has changed over the years in incompatible ways.

The real win of Debian is not, however, its package format, but the distribution philosophy, as exemplified through Debian Policy. This is a statement of requirements and restrictions on packages. Failure to comply with Policy is a release-critical bug, meaning that such a package will not be included in a stable Debian release (unstable/testing of course may include same, but it's still a bug). These policies include management of configuration files, preservation of user data, existence of documentation (both manpages and udner /usr/share/doc), and inviolate (that is, locally managed, outside the package management system) parts of the filesystem tree.

These are attributes of a distribution which aren't apparent sometimes even after years of experience, but which once you become aware of them are very notable, usually by their absense, in other platforms, whether other Linux distros, MS Windows, Mac OS X, or proprietary Unices.

That said, APT and tools seem to be generally more coherent and polished than yum, though yum itself is worlds above raw dpkg or being tied to up2date or RHN.

But they're all (for the most part) compatible, and programs like Alien and Checkinstall make it easier. The same functionality is basically in all of them. And most of them are free.

Autopackage is not exactly loved by the distro people. See commentary from Gentoo, Debian, more Debian... Might be wise to keep those remarks in mind when considering using Autopackage packages on a distribution...

"Alien is a computer program that converts between different Linux package distribution file formats. It supports conversion between Linux Standard Base, RPM, deb, Stampede (.slp) and Slackware (tgz) packages." (From wikipedia)
Homepage
So, create a package for your favorite distro and then convert it into all possible formats.
No support for Gentoo, Arch and other systems though, but Gentoo's users are usually advanced enough to figure everything out themselves.
What I don't like about script-based installers is that such programs don't appear in apt-get or rpm -e, they also don't handle dependencies in a nice way (e.g. automatically downloading them).
So, what I think is best is creating .RPM, .DEB and .TGZ packages, and a script-based installer like nVidia's drivers for users who don't like extracting TGZ but don't have a .RPM or .DEB -capable distro.

Before continuing to recommend Autopackage, you might want to read this post by Joey Hess from the Debian Project, where he calls it "Worst. Package. Format. Ever" and ponders if it was designed by monkeys (and he, the maintainer of Alien, does know a bit about package formats).

If you're interested, you might also want to read this post and the comments there.

Putting your stuff into a version control system, such as subversion and checking it out to a remote machine is a great way to do distributed backups.

I think it's indicative of the quality of this zdnet article that it attributes a page I maintain to Martin Schulze. More details in my blog entry, here:

http://kitenet.net/~joey/blog/entry/secfud-2005-07 -06-11-28.html

Probably not.

Autopackage packages are incredibly badly designed. It's a bunch of shell script hackery, and there's no way to extract it other than to run all the scripts.

If joeyh's comments are anything like right, I'm not surprised. Something about people who do not learn from history comes to mind...

Daniel

The debian guys think autopackage was designed by monkeys. I'd be inclined to agree with them...

Depends what you mean by "you". It may not bother the end user, but it will bother everyone else who needs to do other things than just run your install script.

As others have said, deb and rpm really are quite similar. its the care that goes into making the debs and rpms that varies. Here's a nice comparison of package formats.

Umm, no. I was referring to the program "alien" which converts packages between slackware, rpm, and debian formats. http://kitenet.net/programs/alien/

The guy you remember is Joey Hess. You can find out more here:

CVSHome

The only thing that this'll be useful for, for me anyway, is installing software that companies release RPM-only, binary only that don't have Open Source alternatives.

That's what alien is for.

Oh, well. So you mean you have reinvented alien

At this point, "dependency hell" is pretty much a thing of the past. I say "pretty much" because some distros (Debian) are better than others with their packaging (Mandrake), but apt and the like really have eliminated the problem of not knowing what else you need to install to get one particular thing to install.

Third-party packages may be a different story, but the reason for that should be pretty obvious: sloppiness on the part of the packager. Any distro (or OS) can suffer from this. Yes, even when compiling or emerging software you might just run into a program which insists on having _exactly_ the right version of every library. It's the program's fault.

Now, that has less to do with the Smart Package Manager (the topic of this discussion) than some people seem to think. SPM is just another apt/urpmi/whatever, except that it's supposed to work with RPMs, DEBs and Slackware .TGZ packages instead of just one format. Not a bad idea, not exactly revolutionary either (Anyone remember alien, the package-format translator?) Basically, it's another attempt to make package format irrelevant. And of course, it's still in beta. That's about it, folks.

Yes they can. Alien can convert *.deb to other formats.

The LSB requires RPM be available. I.E. it requires that the distro be able to elegantly deal with and properly install a package presented to it in RPM format. It doesn't say anything about what the distribution's primary package manager is.

Integrating optional RPM support into your distro's native package manager is not hard.

Alien is the util you're looking for, though I'm sure it's not from Slackware itself.

Slackware does come with rpm2targz and rpm2tgz, but (obviously) neither can handle .deb files.

[...]the fact that Joey Hess quit as release manager just recently[...]

Has Debian hit the ceiling in terms of what a volunteer org. can acheive?

It took *forever* for Sarge to come out[...]

I wonder if Joey Hess did say anything (interview, somewhere?) about all of this.

Joey Hess has written up a
retrospective on the new installer. It's a good read.

Here's the summary of the debian-installer from one of the main developers...

Joey Hess blog entry: http://kitenet.net/~joey/blog/entry/d-i_retrospect ive-2004-08-07-19-46.html

//fatal

What?! That's it?!

Those screenshots may just as well have come from the installer with Woody that I've used umpteen billion times. I don't see any different in this "new installer" over the old one. When I hear "GUI" I think "point and click windows/mac style installation". This is just the same curses/ANSI/whatever installer it's always had.

I love debian and I don't see what the big deal is with installing it as it always has been (it's by far the simplest linux distro to install and more straight forward, too) - but ever since I started hearing about this great new graphical debian installer, I've been envisioning something red-hat-ish or something.

*shrug*. *yawn*

On the hardware side, a major shift to Linux wouldn't reduce the number of niche hardware platforms that they'd have to support; indeed, it should increase it. Linux, as open source, will naturally be ported to a huge number of architectures, even more than it has been already.

Linux is Free Software/Open Source. I suspect that Oracle's database server isn't :) Their download page has links for Linux x86 and Itanium (and a preview for OS X, I should mention). I'm not going to sign up for a download account, because I have no need for Oracle's software (the only databases I interact with don't come anywhere near needing Oracle), but I wouldn't be surprised if the stuff is packaged as RPMs for RedHat AS and SUSE Enterprise or whatever it's called (*cough* Novell *cough*... at least the GroupWise java client survived the trip through alien).

I rather doubt anyone in the market for Oracle's software is going to demand to run it on, oh, a Mac LCIII.

That's probably because Joey Hess managed to run a Debian GNU/Hurd image via Bochs. See his journals entries here and his installation report here.

Feel free to add support for BSD yourself, Joey is in no way a Hurd guy, he just did happen to have a BSD installation around or does not care.

Michael

To see the blogs of those involved and commenting, go here.
See Antti-Juhani Kaijanaho and Joey Hess in particular. Anthony Towns (the Release Manager in question) has also blogged on the issue.

True if you haven't done it before. True if you don't know your hardware or are using very new hardware. Otherwise, installing Debian is extremely simple. 11 keystrokes simple.

Debian's new installer's self rolled, text only, very basic stuff.

The people who have been slaving night and day on an 11+ architecture installer with multiple front ends would probably not appreciate that statement, like Joey Hess and the rest.

So users of non-RPM based systems are just out of luck.

Wrong. Even if your distrib doesn't support something like alien, RPMs are easy to tear apart manually.

The code in the driver reveals volumes about how the operation of the hardware works. That's what they want to keep secret from their competitors.

Wrong. They actually want to keep the driver itself proprietary, because they want to keep on selling it. Video-card manufacturers aren't only in the hardware business... they also write software. And they spend much time and money on that software, because it produces real benefits for the customers. Just look at how the performance of NVidia cards changes with driver revisions.

There's no "secrets" in the business. All companies can tear apart and analyze their competitor's products, whether hardware or software. They shy away from Open Source not because they have something to hide, but because they don't want their competitors to be legally able to reuse driver code.

alien