On Thu, 2005-10-20 at 16:32 +0100, Mike Hearn wrote: IMHO that is a bug and should be fixed. However - you can add a directory via placing a file in /etc/ld.so.conf.d/ I believe the standard is that they go into /usr/share/applications. To avoid conflict - desktop-file-install should be used specifying the vendor. For example - in Fedora Extras we use --vendor=fedora which results in the desktop files having a prefix of fedora- If desktop files conflict between two vendors, it is imho a packaging bug by one (or both) vendors. Using desktop-file-install also ensures that desktop file isn't completely broken. That imho is a bug I can't speak to that. I can't speak to that. I assume you mean /usr/local/lib/pkgconfig It probably should be up to the script of a devel package to add that if it needs that but it isn't set already. You could install a script in /etc/profile.d/ if the PKG_CONFIG path doesn't include the path to your pkgconfig files. I can't speak to that. That I consider to be a bug, since the file where it is set has a big warning about not editing it. But perhaps there is a way to add to the searched patch via /etc/fonts/local.conf or in new fontconfig, /etc/fonts/conf.d ? <offtopic> Speaking of not editing that file, it also includes the fake italic and fake bold instructions, which I think in the fontconfig 2.4 branch should be files in /etc/fonts/conf.d/ so they can be disabled w/o editing the "do not edit" config file </offtopic> /usr/local/bin is in my path - if a distro does not include it, it is imho a bug.

On Fri, 2005-10-21 at 03:36 +0200, Bernardo Innocenti wrote: It should come after /bin and /usr/bin - system installed administration scripts may expect behavior specific to the version installed with the system. A user can re-arrange the path if they need to - or create an alias if they need to (probably better).

On Thu, 2005-10-20 at 22:59 -0400, Robert Locke wrote: Heh yeah - you're right.

On Thu, 2005-10-20 at 16:32 +0100, Mike Hearn wrote: Have you checked that this one doesn't work on something recent? I have dumped .desktop files in /usr/share/applications on several FC4 installations and they got picked up and added to the (Gnome) menu (haven't checked KDE though). Looking at /etc/xdg/menus/aplications I'd assume that it's the <DefaultAppDirs/> line that does it (note that there is actually no entry for /usr/share/applications either!) I can't find where the defaults come from at the moment, perhaps they're hardcoded in the panel? /Per

On Fri, 2005-10-21 at 14:03 +0100, Mike Hearn wrote: Boy, I should really learn to proofread better! I meant to say that I had put desktop files in /usr/local/share/applications and it _does_ work on my systems, and I have not changed anything in the menu definition files. (Only tested on FC4 though, I don't have anything older around right now.) My apologies for the confusion! Per

On Fri, 2005-10-21 at 21:46 +0100, Mike Hearn wrote: Actually, as far as I can tell XDG_DATA_DIRS is just not set at all in my environment. (Just checking in a shell, but I suppose the panel should have the same environment.) In this case, the Freedesktop basedir spec says that the value /usr/local/share/:/usr/share/ should be used. ( http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html if anyone is interested in looking at this.) As far as I can see, if the variable is simply not set at all, everything should just work, so just not having the variable set seems like a good default to me. Is this environment variable getting set on a fresh FC4 installation somewhere? (If this was the case, wouldn't it be getting set in /etc/profile or somewhere in /etc/profile.d? I can't find anything about setting that environment variable there.) Mike, could you check if it is actually set on your computer (and in that case where it's getting set)? /Per

On Thu, 2005-10-20 at 16:32 +0100, Mike Hearn wrote: Yes. That's correct. The only software that in considered to be installed is that which is properly installed, using the same method as every other app. Why should Fedora and Red Hat encourage installing software in a non-standard method? How is it easier to have an application that installs in a totally different method from every other app on my system? This isn't a defence of RPM. It's a defence of good systems management. One way to install software is better than two. How do I find out a list of my most recent apps, if half of them are installed one way and half another? How do I find out a list of the largest installed apps, if half of them are installed one way and half another? How do I simply find out what's even installed, if half of them are installed one way and half another? Yes! Because important software shouldn't be installed there. Sweet isn't it? Yes, but most applications are installed using %configure, which makes configure install to /usr. People who run 'configure, make, make install' can easily make an RPM of most applications in under 5 minutes. I'd take about three myself. (List of good things follows) Yes. Anything that encourages people not to install software properly is bad. If you want to improve the packaging system, improve it. Or write your own and make a distro that uses it exclusively. Don't try and encourage people to use two different packaging systems simultaneously. Mike

On Fri, 21 Oct 2005 16:59:38 +1000, Mike MacCana wrote: Because: a) Fedora RPMs are not a standard method. They're proprietary to Fedora and a particular Fedora release at that b) Non-technical end users like this particular non-standard method c) It's more secure to use RPM for operating system level code and something else for 3rd party application code. I'll talk about the last one more in a moment, as I suspect you don't care much for inter-distro compatibility or what non-technical end users want. Have you ever tried it? I don't think ease of use is a real problem with autopackage. Anyway, this set of /usr/local bugs affects installing software from source too, which is still VERY common amongst end users, mostly because software people want is often not available in any repositories. You say this as if it's obvious. But to me it is not. Let's talk about security. Hopefully it hasn't passed you by that despite being basically miniature computers mobile phones have remained basically impervious to viruses and spyware. Yeah yeah, I'm sure somebody can pull up a scare story about a "virus" that requires you to manually confirm reception and installation of the software, and which can then be trivially deleted. But we've seen nothing like what we've seen in the Windows world, where software gets in undetected and then makes itself nearly impossible to remove. One reason is that there is strict separation between 3rd party application code and native OS code. Java MIDlets are an extreme example of that, which can't access or control each other and run in an interpreted sandbox. They also can't access operating system files (although phones do have operating systems and they do store their code and data in regular files). By keeping application/game software totally sandboxed, the platform has been (so far) kept secure. To upgrade the OS you need to reflash the firmware, it's not like installing a regular application at all. Right now we simply *cannot* do that on Linux because there is no distinction between a kernel or libc upgrade and installing a new chat client. When RPM is used for both, how can you possibly sandbox the installation of this software? How can you say, well, THIS rpm can modify the grub configuration but THIS rpm cannot? You could try playing games with digital signatures - RPMs signed by this authority can do anything, and RPMs that aren't signed cannot - but then you did exactly what we did with autopackage and produce a new format. They might have the same file extension but they actually aren't the same type of file at all. They have different capabilities and work in different ways. Anyway. One of the things we've been looking at lately is using the binary policy modules in Fedora Core 5 to sandbox autopackages down so they can't interfere with system configuration in unacceptable ways. We can do that because we control the API and because the format was advertised since day one as a way for developers to distribute their application-level software to end users and not as a distro building tool. You'll never find a kernel autopackage, so the format itself acts as the dividing line. Through this technique and others (like whitelisting) we hope to improve security far beyond what a "one size fits all" tool can offer. Too late. The cat is already out of the bag, 250+ people install their first autopackage every day and it's growing all the time. Why don't you work with what end users want instead of what you believe to be theoretically pure? thanks -mike

On Fri, 21 Oct 2005 16:22:45 +0200, Nicolas Mailhot wrote: Nicolas, whenever I post bug reports or questions here and refer to my project, you bash it. Please, stop. It brings nothing to the table. Now, if you have something to say on the matter of /usr/local support, desktop security or even mobile phones please say it! Otherwise, don't. And for what it's worth, I doubt that not supporting /usr/local is really a "principle". It's probably just been overlooked. thanks -mike

On Fri, 21 Oct 2005 11:25:39 -0400, Jeff Spaleta wrote: Well, LSB RPMs don't bear much resemblance to Fedora RPMs. They aren't allowed any dependencies, for one. For another, Fedora RPMs can't be installed (reliably) on non-Fedora systems, or on versions of Fedora other than the one they were built for. So sure, you could say "RPM is the standard, the LSB says so", but that doesn't make the Fedora-custom flavours of it standard. It makes the LSB flavour standard. And for what it's worth, last time I asked the LSB guys how many LSB RPMs were "in the wild", the answer was perhaps two or three. So it's more a de-jure standard than a de-facto standard. thanks -mike

On Fri, 2005-10-21 at 12:09 -0400, Jeff Spaleta wrote: The FHS and the GNU-standards are fairly widely accepted standards in the OSS, Linux and GNU world. As others already mentioned, the LSB's importance is arguable/questionable - Fact is, its importance so far has been almost negligible. Ralf

On Fri, 2005-10-21 at 13:03 -0400, Jeff Spaleta wrote: Both the FHS and GNU-standards give recipes from "choosing installation directories" and what to install where. To me, this makes at least 3/4's of packaging. I guess you want to re-read the FHS http://www.pathname.com/fhs/pub/fhs-2.3.html and the GNU-standards http://www.gnu.org/prep/standards/standards.html Then we probably have a different notion on packaging. :) Ralf

On Fri, 2005-10-21 at 14:55 +0100, Mike Hearn wrote: Yeah - but that's actually scary. Non technical users aren't going to be watching security lists etc. to know its time to update, rpm is just part of packaging with Fedora - rpm packages can be served from a repository that updates the packages when needed so that the non-technical end user just has to hit a button and have their software updated. Take the recent rtf patch to AbiWord - people using Fedora with the repositories got updates that fixed the issue because the updates were pushed through yum. People using the autopackage - they must find out by some other means that an update is available to fix a problem they may not know exists.

On 21/10/05, Mike Hearn <mike(a)plan99.net&gt; wrote: Autopackage has been "solving the world hunger" for the past few years. It has failed so far (I've seen a bonafide .package file offered to me ONCE in my entire life), and there are no indications that the "tides" will turn. Nobody is interested in a Packaging and Updating System to Obsolete All Packaging and Updating Systems, since every major distribution has already moved on past this problem: * With Debian/Ubuntu you can already install almost any bit of software ever written * Fedora Extras is getting us there * Gentoo et al are also not interested * Linspire has their own system * Proprietary vendors just release statically compiled tarballs, or generally lack clue (usually both) Why are you so set on making it more difficult to support the systems? In our previous conversation on the Ubuntu list, I've already shown you how Autopackage will lead to problems, since its dependency tracking only checks for things that are required by the package currently installed: * foo requires libbaz-1.0, which autopackage fetches and installs * bar requires libbaz-2.0, which autopackage fetches and installs * foo stops working, since its dependency is no longer there If your answer starts with "b" and ends with "undle", then how is this different from LSB RPMs and the aforementioned statically-happy vendors? Can you state clearly the problem that autopackage is trying to solve? As a bonus, can you state clearly how autopackage won't ultimately do more harm by potentially breaking systems or leaving them vulnerable, since it won't do updates? And when it does become smart enough to do updates, can you tell us how your claim that "repositories are not sustainable" will still hold true? It seems to me that you're repeatedly trying to enter a door that's no longer there. -- Konstantin Ryabitsev http://www.mricon.com/

Le vendredi 21 octobre 2005 à 22:16 -0400, Konstantin Ryabitsev a écrit : And now they're experimenting elaborate methods of protecting the system from autopackages. Somehow I'm not surprised. (Not that this kind of sandboxing couldn't be done on top of rpm as the buildsys shows. But somehow we're not feeling strongly this sandboxing need today in the rpm world) Ultimately, when you remove the requirement of the packager to know the system it will deploy on (clueless packagers), and target normal people (clueless admins), you have to find something else to take care of system sanity. I'm less than convinced it can be done automagicaly without reducing the functionality of the system to that of a mobile phone/game console. A computer processes lots of user data, how are you going to decide which data is safe to access from untrusted apps and which isn't ? Of course you can reduce the scope to apps that only access private data, but there's not a lot of them out there. And you only need to care about user data. If reinstalling a clean system was not fast nowadays, FC couldn't have had a short release cycle. -- Nicolas Mailhot

Mike MacCana wrote: Forgetting about autopackage for a moment, /usr/local *is* a traditional place for administrator-installed software. It does not sound inappropriate to take it into account in the overall system setup; even if the typical system administrator might be well able to do that by himself, he's likely to appreciate the effort nonetheless. In my opinion, the problem of third-party (meaning not provided by the distribution) applications is supposed to be solved by /opt, but the suppport for /opt across distributions is arguably even less developed than for /usr/local. So maybe the real answer is "provide support for /usr/local and /opt integration". Just my $0.02 Davide Bolcioni -- Paranoia is a survival asset.

On Fri, 2005-10-21 at 18:34 +0200, Davide Bolcioni wrote: On Linux, most administrators install software by RPM, and no distinction is made between 'third party' or distro provided except the Packager field. Mike

On Wed, 2005-10-26 at 11:07 +0200, Davide Bolcioni wrote: True, but this only is a side-effect ... ... of this, because _vendors_ are supposed to install to /usr. => vendor supplied rpms normally do not end up below /usr/local. Also, in a strictly FHS-compliant world, you would install all non-vendor supplied packages to /usr/local and would not replace any vendor supplied package nor file. I.e. to install rpm packages to /usr/local you would have to build them with a different package name and different %_prefix, %_bindir etc., than a vendor would do. As this is beyond most people's capabilities (and because most vendor supplied rpm specs are not prepared for this), most people often simply replace the vendor supplied packages below /usr, instead. Strictly speaking, they violate the FHS, when doing so. Ralf

On Fri, 2005-10-21 at 16:59 +1000, Mike MacCana wrote: I agree with you that rpm is the proper way to install software on an rpm based system. However, some software is not available as rpm - and I don't believe that the end user should be responsible for creating an rpm themselves. There should at least be basic support (IE ldconfig knowing about stuff in /usr/local/lib) for installing software from source, which would also allow tools like autopackage to install there and not conflict with the rpm system.

On Fri, 2005-10-21 at 21:26 -0700, Kenneth Porter wrote: Yes it is. If you know how to do it. I only install software on my system through rpm. But being relatively simple for someone like me does not mean it is relatively simple for other people, and it does require a learning process. Some upstream tarballs contain a generic spec file that works on most systems - then you can just do rpmbuild -ta foo.tar.gz but I've actually found quite a few that have packaging errors themselves. Then there's issue where DESTDIR support is not always proper and some patches to the Makefile need to be added, gnome applications will require you to disable gconf updating during the install and do it in the post script, etc. Users should not be expected to learn how to package rpm's unless they need to learn it for another reason. I do think that developers should learn rpm so they can provide a *quality* generic spec file, some spec files I've seen are just scary (and often not generated by autoconf so the version ends up being wrong if they don't remember to manually update it for a new release)

On Sat, 2005-10-22 at 01:11 -0700, Kenneth Porter wrote: Yes - many projects have foo.spec.in When autoconf is run to generate the configure file, foo.spec is generated - thus you can have version information etc. inside the spec file that does not need to be maintained by the developer (ie use @VERSION@ for the Version header info)

On Sun, 2005-10-23 at 06:33 +0200, Ralf Corsepius wrote: Correct - foo.spec.in has to be added by the developer, and maintained by the developer.

Hi The best way to tackle this is to file independant bug report for each of these bugs against the appropriate component in http://bugzilla.redhat.com. It would probably be useful to post a list of the bugzilla numbers for future reference. regards Rahul