+1 Op 21-jan.-2014 07:37 schreef "Louigi Verona" <louigi.verona(a)gmail.com>om>:

On 01/21/2014 07:50 AM, Nils Gey wrote: I don't expect package maintainers to get a fresh new software into their distro right away. Even when they do it's most likely to the next / unstable / testing repository. Most of the time users have to wait until the package is backported, if that ever happens. That takes away to "freshness" of the software (and the excitement to try it out). When users are unable to use your software, they will eventually forget about it. Heh, even for some github repos some developers know that if they want any usage on win or osx they have to release a testing binary. Most Linux (audio) users used to be developers as well, I don't believe that's the case anymore.

On Tue, 2014-01-21 at 09:44 +0100, karl(a)aspodata.se wrote: +1 Developers are free to provide packages and they are free to include the needed dependencies. Take a look at the file system hierarchy standard regarding /opt. Btw. AFAIK there are two projects working at a new file system hierarchy to make it easier to install software, what ever this means. Instead of using Debian and all the other named distros users are free to install a modern distro that is more stable than those oldish distros and anyway more up to date and especially not splitting into several packages. Such a distro might provide an easy to understand package management too. How about Arch Linux? +1 More and more optional dependencies become hard dependencies. People care about disc space and want split packages, so that they aren't forced to install the headers, but it nowadays is ok to install tons of packages that aren't needed and that not only need much disc space, but that could serious issues, such as pulseaudio and gvfs. In the early days pulseaudio tend to stop working audio on many machines and gvfs still today damages "green" drives. Very alarming is that fast 3D graphics become requirements and that people want the same kind of "desktop" environments they use for their smartphones and tablet PCs for the desktop too. Sorry, a little bit OT. Some developers already build packages. Some distros, e.g. Arch at least provide much more good multimedia software than e.g. Debian, but even for Debian users could install third party repositories to get rid of many issues. Building from source does work since many years even for completely inexperienced users.

On Tue, 2014-01-21 at 09:01 -1000, Joel Roth wrote: The problem is that I don't remember it and when I google for it, it seems to be that I confused it with something else. IIRC there where plans to make it easier to install software independent of dependencies. Perhaps a misunderstanding or wrong remembrance. I guess each software should get it's own directory, similar to /opt/software_foo.

On 01/21/2014 03:44 AM, karl(a)aspodata.se wrote: Is it really simply black or white? Must it be *that* way or the highway? The reason my main PC is a linux distribution is because of choice, not because I like compiling my own software, Although I do compile (and develop), I much prefer typing 'yum install <package> <package-devel>' when I need to satisfy dependencies. Choice, choice choice. Although I'm not familiar with all, I'm pretty sure there are bare-bones distributions. If there aren't, well, you have to choice to create your own. I agree. Perhaps a bit elitist. I don't know *any* windows or mac user (non-system administrator) that ever took a course besides possibly online "getting started" videos. I do agree that education would help but open-source software authors aren't usually the most prolific documentation authors (myself included). I find this quite nice, to be honest. If I need the headers, I grab them, if not, I don't -- again, choice. Fair enough, but why cut down binary distributions? If the software developer wishes to create a binary, more power to him/her -- again, choice. That's what makes linux strong. David

On Tue, 2014-01-21 at 16:29 +0600, Zlobin Nikita wrote: Often there aren't packages for much wanted software available regarding to license policies of distros. When users want to use a computer for multimedia productions, the users perhaps should reconsider if it's smart to use such distros, especially when using third party repositories could cause issues. However, sometimes developer should think about using licenses that don't cause issues or not to use e.g. codecs that might cause license issues.

On Tue, 21 Jan 2014 12:40:23 +0000, Fons Adriaensen wrote Finally some wise words. Thanks. I think most posters so far totally underestimate the part of the distribution. Distributing software as part of a distribution is much more than just compiling the binary and putting it into a package. Again, I think "Linux" stands for "some distributions". And even if they can't: use your distribution's package or file a request for packaging. There might even be valid reasons for why a package is not availabe in the newest version. Space is _not_ the reason for these splits. On Unix it's perfectly ok to have several versions of a library installed in parallel. But it's not possible to install several versions of the header files in parallel. Thats a result of the way C handles includes. I found that part amusing. Does the OP really claim a toolchain that can create binaries tha run native on 32bit inteloids as well as on 64 bit AMD/Intel. Will his binary run on my PPC (Mac Mini, great tool to run Aeolus). Not even speaking of the plentitude of (binary-incompatible) ARM processors. And do theses binaries magically create MMX/SSE/SSE2 instructions on thoses CPUs that don't have them? Or are we blessed with binaries with all optimizations dissabled? Such a toolchain is either fantastic or ridiculous. N.B.: I love the idea of "More binaries for small and obscure software, ..." Yeah - obscure software (from obscure websites?), as a binary blob. Just double-click to install (and, pleeeease, run it a root :-) I'm getting old :-/ Cheers, RalfD -- R. Mattes - Hochschule fuer Musik Freiburg rm(a)inm.mh-freiburg.de

On Tue, 2014-01-21 at 15:55 +0000, Filipe Coelho wrote: But that should be provided, if it shouldn't be provided, then taking a look to the makefile might give some hints what was installed to what location. Btw. it can't harm to at least try checkinstall instead of make install, this is possible most of the times. Restoring from a backup? Even non-techie (non-power-users) should consider to backup their complete Linux DAWs and data.

On 01/21/2014 04:07 PM, Ralf Mardorf wrote: Well, first, it's up to the developers to provide that and not the user. Second, I don't think *any* new user will understand what a Makefile does... Regarding checkinstall, that's not a widely known trick. I still meet new users on IRC and forums that never heard of it. How do you backup an installed application? In my case I had an older version of an app I wanted to upgrade. The distribution didn't had the new version so I had to build one myself. Because I was a noob something probably went wrong during the build, resulting in a broken app. The app installed to /usr/local which overrides distro's /usr packages. But I didn't knew that (noob alert ;)) so what could I have done? Reinstalling the app's package did nothing (still /usr/local files present). For a new Linux user, I understand this is when they start thinking about going back...

On 01/21/2014 04:31 PM, Ralf Mardorf wrote: hm, so you're saying users should boot a live media everytime they want to compile some software? Yes, Linux is still only 1-2% of global pc users. It should be expected that most new Linux users come from other OSes. Everyone will have different reasons. Speaking for myself, I wanted to try something different and also stop with the piracy. I believe this too. Each OS works in different ways. My post is not about this though. It's about new linux users are having a very hard time getting new software to work for them. I still have issues with mailing lists... I never liked them, and don't believe I ever will. I might be wrong on this, but I believe most "non-techie" users have never used mailing lists (or even IRC). It was surely a surprise to me at first.

On Wed, Jan 22, 2014 at 7:41 PM, Fred Gleason &lt;fredg(a)paravelsystems.com&gt; wrote: 'upstream/downstream' division of labor — it is, after all, pretty much unique to the FOSS world. Your suspicions are wrong there: Filipe maintains many packages for KX Studio ( http://kxstudio.sourceforge.net/ ), and has extensive experience in the area. He's also very commited to ensuring up-to-date packages: something that requires a lot of dedication, as I'm sure you know since you package too.

On Tue, Jan 21, 2014 at 12:40:23PM +0000, Fons Adriaensen wrote: I'm inclined to agree with Fons here. There seems to be a growing culture of expecting Windows-style hand-holding for free software. In the Windows (and Mac) world you pay money for this. I think it's unreasonable to expect the same level of support from unpaid developers. (If they have the time to do it that's great, but it shouldn't be taken for granted). John

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for the duplicate, John, pressed the wrong button ;D On 21.01.2014 14:11, John Rigg wrote: Interesting. I had a discussion on a related topic with Filipe on IRC just a few days ago: What kind of choices should a software make for the user? In our example it was the usability (inversely correlated to the number of actions required by the user (mouse clicks, etc.)) of e.g. a free connection patch canvas vs. e.g. a mixer strip which restricts the signal flow to be linear for a usecase of e.g. adding a plugin to a plugin host and getting sound out of it. My opinion is: It is very much OK for a software to make choices to streamline common usecases if it happens to be not at the expense of the freedom to accomplish the more complex task. In our example this would be a mixer strip abstraction over the free patch canvas, but where the user has the option to change to the free patch canvas if desired. I see it somewhat similarly here. Providing binaries for software does not restrict the user from downloading the source package and compiling the software itself. We're not discussing providing binaries ONLY, but providing binaries as convenience for a common usecase. Have fun, Flo

On 01/21/2014 12:40 PM, Fons Adriaensen wrote: Enough for most users to install your software. See my next point. I think it's not up to the users to understand how software compilation works. Car drivers don't need to understand how a car engine works. It helps sometimes, but that's usually a task for the mechanic. Some distributions are making compilation specially hard. Most source tarballs install to /usr/local, but in Debian (and maybe others) that dir is not considered by pkg-config. Example: building stuff like NTK and then NON will result in an error (NTK is a dependency of NON apps). Although NTK was installed before, users need to manually setup PKG_CONFIG_PATH for NON software to see it... I seriously don't wish any new user to have to put up with this. It might be easy for us that are now used to this sort of things, but not for them. It's not always easy to figure out the header package files. (like ALSA = libasound2-dev) Also in Debian installing libjack-dev changes your current JACK version from jack2 to jack1. We need to install libjack-jackd2-dev instead... :S It won't create packages, it will create binaries - which is what users are looking for. Take a look at what happened to the recent release of deteriorate-lv2. Author released only source code, so users have to compile in order to use it. But due to a variety of reasons it's failing for some of them. Those users will simply skip the software and not use it, because well, they can't... If there was binaries, users could try that first. Commercial software always releases binaries (they have to anyway), and I don't see the users complaining much about those. When done right, binaries can cover most Linux users, which will be happy to be using software instead of trying to figure out dependencies, paths, headers, etc etc.

On Tue, Jan 21, 2014 at 03:34:05PM +0000, Filipe Coelho wrote: That depends on the developer's intention when releasing source code. Some very good Linux audio software was written for the developers' own use, and the source code only released as a favour to those who might also have a use for it. Some of the LADSPA and LV2 plugins I use most fall into this category. If a piece of free software isn't available as a distro package, I think it's very much up to the user to find out how to compile it if the developer doesn't have time to offer unpaid support. John

On Tue, Jan 21, 2014 at 03:34:05PM +0000, Filipe Coelho wrote: Then they should wait until their distro or someone else provides a package. Or pay someone to do the work for them, just as they have to for commercial software, or for the mechanic you mention. Or use a distro that usually provides a shorter release cycle, e.g. Arch (which is not for noobs). And how are these installed ? Bypassing the distro package management is a sure recipe for misery. Maybe not immediately, with a bit of luck the binary you just copied to /usr/bin may work. But sooner or later your users will get some serious trouble, because you're messing up their systems. If that's what you want, go on... Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

On Tue, Jan 21, 2014 at 05:11:10PM +0000, Filipe Coelho wrote: Really ? Package managers don't care about /usr/local and will never touch it. It's a completely separate world. It exists just for that reason. They *do* care about /usr/bin and /usr/lib. Managing those dirs (and some others) is why package managers exist in the first place. Because in all except the most trivial cases, installing an app and making sure it works will involve a bit more than putting a binary in /usr/bin. Oh dear. Such naivity is really touching... Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

I kinda knew this would turn into an ideological debate. As a user and not a developer, I would like to point out that the problem with compilation is not that it is not "rocket science", but that it is a tedious process that not all users want to go through even if they know how to do it. Back in my days of being new to GNU/Linux I compiled a lot of software and even when being keenly interested in doing that I remember being very frustrated as I can rarely recall an occasion when it just worked. That means that if you do not have all the tools and dependencies, you know as a fact that installing this application will take unpredictable amount of time. Once it'll take you 2 minutes, another it can take up to a day, which had happened to me. Which is why I personally rely more on ppa's nowadays as I am a little bit tired of compiling things. There are some programs that I never could compile at all, for one reason or another. So, this has very little to do with learning or intelligence. This has to do with priorities. If a person's priority is to develop and not use, then sure. If a person's main goal is to use GNU/Linux software, then his priority would be to get it running, not dive each time into the intricacies of how things work on code level. Not to mention, fellas, that there is not much learning value in compiling anyway. I mean, sometimes you just don't have all the dependencies and after you go through the trouble of getting almost all of it, some library requires you to have a different kernel version and there's that. And in conclusion, I'd like to note that Filipe's suggestion is just that. If you do not agree - you won't use his methods and will continue to release sources. Those who agree will try out his way. So I see no problem here. L.V. *http://www.louigiverona.ru/ <http://www.louigiverona.ru/>*

On 01/21/2014 05:57 PM, Ralf Mardorf wrote: That's why I'm planning to do a small, *developer*-oriented tutorial on how to get the most "generic" binaries possible. Something that can work as widely as possible. Have you not ready my first post at all? tablets are a different ecosystem, we should ignore it here. The desktops systems usually have a way to downgrade - just uninstall your current version and install the previous one. A good example of this is uTorrent. Users are not happy with the last releases (includes ads and bloated features), so they download and install an older version. Having different versions of an app it's not unique to Linux. PS: I'm ignoring the rest of your post, it doesn't seem to me to have anything to do with the matter at hand.

On Wed, 22 Jan 2014 16:49:06 -0500 Fred Gleason &lt;fredg(a)paravelsystems.com&gt; wrote: This is assuming some DE, and I guess such efforts are limited to the two largest DEs out there. Also DE specific, I assume. Or systemd, or ... Or pacman or ... It honestly bothers me when stuff is geared towards specific Distros or DEs or package managers. Some people doing this stuff simply ignore (or can't conceive) that there are other possible ways to do stuff. One example I came across recently is this ticket regarding dbus: https://bugs.freedesktop.org/show_bug.cgi?id=50955. Reading the comments it seems to me that dbus was written with RPM in mind, completely ignoring that other systems might do things differently. It's not even a big difference in this case. Distribution guys really shouldn't write system software. Regarding the DE integration... well, I get the impression that too many people assume the users are running gnome, or KDE, but mostly some form of gnome these days. Shouldn't the DE guys bother with DE integration, and maybe try to push it upstream? They apparently don't do that, so this is mostly left to packagers. I don't even want to know how much duplication of effort is going on there. I also don't like how much packagers seem to focus on DEs (mostly gnome). It may be practical to assume a mono culture, but we are luckily not there yet. Sorry for the rant. Regards, Philipp

On 01/21/2014 07:10 PM, Filipe Coelho wrote: ??? "linux" (as in 'kernel') does not provide anything related to that. concerning "linux" (as in 'distribution') i can only speak for one: Debian explicitely does *not* support downgrading. my experience with ubuntu is small, but i gather that it doesn't even properly support upgrading. different to what? a considerable amount of computers sold are "tablets" there days. a considerable amount of tablets are running "linux" these days. as a matter of fact, i think this entire discussion makes *most* sense in "tablet world". gfmadsr IOhannes

On 01/25/2014 07:55 AM, hermann meyer wrote: if your only requirement for *grading is replacing some files, removing some others and installing yet another set, then `dpkg` can do this nicely. (and ubuntu fully inherits the merits of dpkg). unfortunately, *grading is often more than that. just think of files created by the application that has to be readable by another version of the same application. gamd IOhannes

On Tue, 2014-01-21 at 12:40 +0000, Fons Adriaensen wrote: Bingo. ... and packagers are much more adept at this than most upstream developers. It's not a very effective use of developer time to spend a ton of it making binary packages. n hours I spend doing that is n hours I *don't* spend improving the actual software. There are many people in the world who can and do the packaging part, and few who can and do effective work on the code. Packagers provide a valuable service; having upstream developers try to emulate commercial software distribution methods (against platform norms, making their software weird and annoying) would be a giant step backwards in several ways. So, thanks, packagers. If you want to make universal binary packages for most Lignux systems, by all means, feel free. I sure won't be. -- dr

On 01/21/2014 01:40 PM, Fons Adriaensen wrote: Exactly. "Releasing source code is not enough". Again exactly. If you want downstream maintainers/packagers to do the hard work in producing trusted binaries so that you will never get an email about why won't this build again, there's a few things you can do: - be a absolutely clear in your licensing. the upstream author of this plugin sent me an email and said I can use this code is not good enough - don't bundle libraries. It's lazy and its insecure insecure. If upstream has a major problem with you - fork it. Look at ntk for an example. - become a package maintainer, you are doing all the hard work anyway kxStudio would be great in Fedora ;) If people don't know how to find devel packages then they shouldn't be compiling software. The fact that the need to is a mistake. I really recommend that people should really petition their distros first before trying to build the latest release themselves. Encourage users to file bugs to both distro and/or maintainer. More often than not the downstream packager does not even realize a new version exists. I'm maintaining >100 Fedora audio packages and it is hard to keep up. Brendan

On 01/21/2014 04:40 PM, Philipp Überbacher wrote: This point is exactly why I think binaries are needed. There are no such thing as "magic binaries", nor have I stated I have them. But I think *trying* to provide binaries is better than none at all.

On 01/21/2014 05:09 PM, Gene Heskett wrote: That's why I want to make a developer-oriented tutorial about this. It will explain how to get gcc4.8 in an old Ubuntu 10.04 chroot, together with a few static libs as well. (It's the same method I'm using for building generic debian packages) I've been using this for my own software binaries and the only complaint I received was about a CentOS user (it required qt >= 4.6, which he didn't have).