| |||||||||||||
6.0: The beginning of the end for AV Linux (The H)6.0: The beginning of the end for AV Linux (The H)Posted Aug 18, 2012 2:16 UTC (Sat) by bats999 (subscriber, #70285)Parent article: 6.0: The beginning of the end for AV Linux (The H)
From Gmaq in the comments:
"Linux is wonderful in so many ways but at the development level a lot of the 'freedom' more closely resembles anarchy and the never ending shifting sands of the underlying support libraries and the unbelievable amount of babysitting and building from GIT, SVN etc, required to maintain 50 or so applications is simply not possible for me to continue and lead a balanced life."
Could the LWN readers who maintain distros share insight into how they face these challenges? Tools that have saved your sanity? Organizational approaches?
(Log in to post comments)
6.0: The beginning of the end for AV Linux (The H) Posted Aug 18, 2012 3:24 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
I maintained my "distro" based on LFS for our devices. Yep, there was too much insanity. WAAAY too much.
We'd switched to Debian for MIPS and our life got infinitely better. We've even got enough time for things like sleeping :)
6.0: The beginning of the end for AV Linux (The H) Posted Aug 18, 2012 8:40 UTC (Sat) by kleptog (subscriber, #1183) [Link]
I havn't done much package maintenance myself but I've created the occasional Debian package. What I've noticed is that over the years the tools have gotten better, but one thing hasn't changed: developers do not know how to release software in a way that makes it easily to distribute.
This isn't surprising, it's not a course you can follow. You learn only by seeing how other people do it. Though the rise of alternative build systems like cmake en autotools have reduced the number of sharp corners.
In the beginning the debian/rules file was a makefile you made that described how to build the software, I guess similar to the Gentoo ebuild. Nowadays you have debhelper which has so much intelligence that it correctly guesses defaults for a large number of build systems and builds a decent package. The rules file can be almost empty.
My guess though is that much of the software that makes AV Linux special is of the kind where the quality of the build system is "a makefile that works for me", and turning those into decent packages is a *lot* of work.
6.0: The beginning of the end for AV Linux (The H) Posted Aug 18, 2012 8:55 UTC (Sat) by pabs (subscriber, #43278) [Link]
For folks who are writing software as upstream, please take a look at Debian's (incomplete) guide for upstream developers and also the links in it (my favourite is Tom Callaway's list of FAILs). Debian current pushes new packagers to read this when we find out they are also the upstream devs.
6.0: The beginning of the end for AV Linux (The H) Posted Aug 18, 2012 13:10 UTC (Sat) by cabrilo (guest, #72372) [Link]
I maintain several in Arch Linux's AUR. These are "user contributed" packages and there is no quality check on them so I can't really speak with high authority on this issue.
As far as tools are concerned: it really depends on the distribution and packaging systems - they all differ.
However, after maintaining a package for some time, you get to learn about how the upstream functions, so you just subscribe to their mailing list and watch for changes. If something doesn't work for you, you either contact upstream for a fix (and they are often very responsive, but of course it depends on individual developers) or try to provide your own patch.
Some packages take more work then others - e.g. some always work straight out of tarball, and some make you jump through hoops just to install them in /usr instead of /usr/local, or make them work with your distro's version of a library.
With 3-4 packages, that's a breeze. It's even fun and that's why I do it.
With dozens of packages, it's a different story... You can have all the tools for building a package in the world, but there is no easy way to package software which depends on an ancient version of a library which you don't care to include in your distro, or requires a brand new git checkout to make it work.
Resolving those issues, patching things, spending days on mailing lists, etc. is what gets you. Users of Linux distros don't go through dependency hell anymore because packagers do it for them. And they have to balance and shuffle packages for the entire distribution, and not just a single installation. It's all too common for two pieces of software to require two different versions of a same library...
|
|||||||||||||