Re: RFE: Never, ever steal focus.
nodata writes: Am 2010-01-06 18:17, schrieb Matthew Booth: On 06/01/10 17:00, Adam Jackson wrote: On Wed, 2010-01-06 at 11:36 -0500, Jarod Wilson wrote: On 1/6/10 11:07 AM, Adam Jackson wrote: PGA. Here's the challenge. To reply to this mail, I hit control-shift-r in one evo window, and evo opened a new window for me to compose into. Get it? I typed into one window, and then started typing into another, and that's exactly what was desired. If the window manager suppressed focus changes on the basis of you were just typing into some other window, this must be a focus steal, then the new compose window would have mapped unfocused, and I'd have to have alt-tabbed to get to it. So if you can come up with an algorithm that can reliably classify focus change requests as stealing or not, then great. I'd go with don't let a different app steal focus. Windows for the same currently focused app are allowed to. This works pretty well under Mac OS X. Might depend on some of the stuff being done by the gnome-shell folks though, to be able to group windows together as belonging to the same process/application to be able to do it Right under a Linux DE... Now make that work for the (not uncommon) case of clicking a link in evo or control-clicking one in gnome-terminal and expecting firefox to pop forward with that page. There is one situation where the absolute of $SUBJECT is required: password windows. I end up typing passwords wholly or partially into other windows on a reasonably regular basis because of this. Matt This is my primary motivation for bringing this up again. I either start typing a password into a dialog then something steals focus and the password is in cleartext, or or the other way round: I start typing something in one apps, a password dialog pops up, and I end up typing non-passwords there. Ugh. Dangerous and not good. This must be solvable, not just for password entry. I think this is an application's responsibility. An application should properly specified when it pops up a window whether it should take user input focus. If something improperly steals focus from another application, I would consider that an application bug, pgpbTB7FnphN1.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Fedora 12: Emacs is not for software development
I just did a new install on a spare laptop. I chose the Software Development option. Emacs did not get installed. Also, although neither mysql-devel, nor postgresql-devel, nor even libtool-ltdl-devel got installed, I ended up with a huge number of -devel packages, many of whom, from my viewpoint would like have an audience much smaller than emacs' potential audience. Although an argument could be made about mysql and postgresql, I suppose, leaving emacs off is rather depressing, if that accurately represents the contemporary general opinions. pgpwoknvPYcWl.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12: Emacs is not for software development
Rahul Sundaram writes:
On 11/28/2009 02:12 AM, Sam Varshavchik wrote:
I just did a new install on a spare laptop. I chose the Software
Development option.
Emacs did not get installed.
Also, although neither mysql-devel, nor postgresql-devel, nor even
libtool-ltdl-devel got installed, I ended up with a huge number of
-devel packages, many of whom, from my viewpoint would like have an
audience much smaller than emacs' potential audience.
Although an argument could be made about mysql and postgresql, I
suppose, leaving emacs off is rather depressing, if that accurately
represents the contemporary general opinions.
Why? It's just shows your personal preference for a editor. Emacs is
certainly not needed for software development.
Ok, that's a valid question. So let's see what got installed:
$ rpm -q --queryformat '%{NAME} %{GROUP}\n' -a | fgrep Applications/Editors |
sort
emacs Applications/Editors
emacs-common Applications/Editors
gedit Applications/Editors
nano Applications/Editors
vim-common Applications/Editors
vim-enhanced Applications/Editors
vim-minimal Applications/Editors
I installed emacs myself. So, all I got was gedit, nano, and vi.
I am quite comfortable with either emacs or vi, for different editing needs.
I am sure you can also do software development with nano. But that's quite a
stretch.
Let's say I want to do software development. I make an appropriate selection
when intalling Fedora 12. What editor am I expected to use?
With emacs, I get major modes for C++, Java, Perl, Python, XML, and a bunch
of other things. That's quite a mouthful. The others, in this list, don't
offer much more than notepad in Windows.
pgpdMgm8n0stL.pgp
Description: PGP signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 12: Emacs is not for software development
Debayan Banerjee writes: 2009/11/28 Rahul Sundaram sunda...@fedoraproject.org: Why? It's just shows your personal preference for a editor. Emacs is certainly not needed for software development. Well one does need an editor for development. Assuming vim and emacs have roughly equal user bases, chosing emacs over vim for the Actually, they chose vim over emacs. distribution shows Fedora packagers' personal preference too. I guess both vim and emacs should be available. pgpvhEoGCchDE.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Broken dependencies script at it again
Tom Lane writes: Mike McGrath mmcgr...@redhat.com writes: Are people +1'ing getting rid of the broken dependencies script altogether? or +1'ing to predicting the future and stopping it before it breaks? I thought the +1's were for putting in some circuit breakers, so that when (not if) it breaks again, it won't spam the entire package Proposed circuit breaker: if more than 5% of packages supposedly have broken dependencies. pgpijnctyywJF.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora with Universal Binaries?
Pete Zaitcev writes: On Thu, 22 Oct 2009 12:28:36 -0500, King InuYasha ngomp...@gmail.com wrote: I just saw this article about an effort to create Universal binary style ELF binaries for Linux, and I thought that this would be something to watch, so that Fedora could integrate both x86-32 and x86-64 into single DVD sets. Sounds like a kludge to work around limitations of dpkg. Not really. Something like this would allow you to have a single boot image for both 32 and 64 bit hosts. 32 bits will be here for a long, long time, of course, but its days are numbered, so I don't think it makes practical sense to invest the effort in implementing FAT ELF format. There might be some practical benefit if its scope was expanded to support arbitrary binary ABIs, i.e. a single ELF image containing x86_64 and sparc64, perhaps. pgpPUNmFHH98g.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Build requirements for threaded code?
Michel Salim writes: On Wed, 2009-08-19 at 19:57 -0700, Roland McGrath wrote: -pthread means -D_REENTRANT and -lpthread. -D_REENTRANT is basically useless and you should use standard feature test macros or _GNU_SOURCE for what you want. So just linking with -lpthread is what I would call the normal and recommended practice. The man pages are not maintained by people who ask the people who know. Which raises a good question: who ought to be in charge of the manpages? There ought to be a good way, once a problem is found (like in this case), for the relevant manpage to get fixed. The pthreads man page contains the maintainer's contact information, at the bottom. pgp9Jq0mLQa69.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Build requirements for threaded code?
Tom Lane writes: This might be a stupid question, but: what compile and link options are necessary nowadays for multithreaded code? I see various references to -pthread and -lpthread, but it's hard to be sure what's authoritative. Just -lpthread does the trick for me. The -pthread option is needed on other platform, not Linux. pgpylxOALwM8A.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Visiting webpage causes ~hard lock - round 2!
Dr. Diesel writes: Please save your work and visit (tech website): URL:http://hardforum.com/showthread.php?t=1391450amp;page=13http://hardf orum.com/showthread.php?t=1391450page=13 Screen freezes, mouse has jerky movement, vt switch fails. Loads fine for me. F11.i368 all updates as of today, nothing good in /var/log/messages Same here. This subject is better suited for fedora-list, follow-ups set. pgphb2IiUxp2N.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Indeed. Here's an idea -- why don't you mass mail the maintainers of all the autotools-using projects you can find on Sourceforge, and be sure to tell them how much autotools suck, and how better CMake is. I'm sure they will appreciate your helpful suggestions. Hahaha… Do you have any SERIOUS suggestion on how to bring the deficiencies of the autotools to the attention of upstream maintainers? Of course spamming them won't cut it. What's wrong with what I suggested? If you truly believe that cmake is so much better, I'm sure that everyone would be glad to hear it. Go ahead, state your case. I'm the upstream for two packages in Fedora. Make your case. You can start with me. pgpiFHLTRq2JY.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Wrong, as usual. That's an ad hominem argument. Since each autoconf macro typically expands out to hundreds lines of shellcode, But those hundreds of lines of shellcode *CHANGE* with the autoconf and/or aclocal version! You're changing the topic. On this point, we're not talking about what happens when autoconf changes. Here, the original statement was that patches to configure.ac are less likely to be kicked out than configure, if configure.ac changes. I pointed out that this is completely absurd, and you have no idea how autoconf works. You have no answer, so you must now start talking about what happens when autoconf itself changes. with the autoconf macro's parameter embedded somewhere in the middle of all that stuff, were you to change a parameter to an autoconf macro in configure.ac, and upstream changes the parameter in the next line, your patch gets broken. Upstream is much less likely to change that parameter in the next line than to use a different version of autoconf. Do you have any data to back up this interesting notion -- that most changes to configure are due to autoconf version changes, rather than upstream making changes to configure.ac itself? I thought not. Yes, tell me again how conflicting patches to neighboring lines in configure.ac works, while the equivalent two patches hundreds of lines apart in configure do not. You don't understand me, I'm telling you how patches to configure.ac in an area upstream is unlikely to touch any time soon work, while the equivalent patches in configure get fuzzed by unrelated changes introduced by a new autoconf used by upstream and break. This is absurd. configure.ac changes due to natural evolution of the package far more often than autoconf itself changing. In fact, many actually loathe switching to a different version of autoconf, preferring to stay on the same version as long as possible. Stuff like AC_PATH_PROG produces several dozens lines of canned shellcode, with the arguments to AC_PATH_PROG appearing once, in the middle of them. But those several dozens lines of canned shellcode CHANGE WITH THE AUTOCONF VERSION! Which happens far less often than routine changes to configure.ac, as the package natural evolves over time. autoconf changes happens maybe once every other year or so. Most configure script change far more often than once every other year. This is a bogus argument. Changing the parameter to AC_PATH_PROG, for example, does not change hundreds of lines of shellcode. No, but using the next point release of autoconf, even with no changes to configure.ac at all, does. Most programmers use fast-moving distros. Distros like Fedora, Debian It would be trivial to pick a typical package, and look at intervening releases, years apart, and observe the major differences in configure.ac, yet, perhaps only one, if none, update to autoconf itself occuring in all the intervening releases. But, once I do that, you'll abandon this reasoning too, once you realize that it's a non-starter, and change the topic to something else. It'll probably be line number changes. pgpLl1IzIrr9G.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Richard W.M. Jones writes: On Tue, Jul 07, 2009 at 06:05:47PM -0400, Sam Varshavchik wrote: If someone thinks that by patching configure.ac, instead of configure, one achieves tremendous savings in the frequency of needing to rebase one's patches, they're in a desperate need for a reality check. No, you are. Please find out how patch works. I do. Which is why you cannot hold your end of the debate. pgpK2RTQZZHlX.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what rediffing means for us Fedora packagers), is more likely to break for configure.ac than for configure. And that's exactly what I said. Thank you for agreeing with me, that fixing configure is less likely to cause problems in the long run. Which happens far less often than routine changes to configure.ac, as the package natural evolves over time. autoconf changes happens maybe once every other year or so. Most configure script change far more often than once every other year. I don't know what upstreams you worked with. For the projects I worked on with Romain Liévin, he generally ran autoreconf with what was current on Debian unstable or testing that day and me with what was current on Fedora (stable updates) that day. The stuff would even ping-pong between the Debian Well, I don't know what those projects were, but here's a better known example. I just downloaded all available versions of the 2.4 branch of openldap, and greped their configure script. The results are: openldap-2.4.6/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.7/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.8/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.9/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.10/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.11/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.12/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.13/configure:# Generated by GNU Autoconf 2.59. openldap-2.4.14/configure:# Generated by GNU Autoconf 2.61. openldap-2.4.15/configure:# Generated by GNU Autoconf 2.61. openldap-2.4.16/configure:# Generated by GNU Autoconf 2.61. Now, let's grep configure.in: openldap-2.4.6/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.7 2007/10/16 23:43:09 quanah Exp $ openldap-2.4.7/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.7 2007/10/16 23:43:09 quanah Exp $ openldap-2.4.8/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.9/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.10/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.11/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp $ openldap-2.4.12/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.14 2008/09/17 22:54:33 quanah Exp $ openldap-2.4.13/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.17 2008/11/21 01:26:24 quanah Exp $ openldap-2.4.14/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ openldap-2.4.15/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ openldap-2.4.16/configure.in:dnl $OpenLDAP: pkg/ldap/configure.in,v 1.631.2.22 2009/01/26 21:54:23 quanah Exp $ Over a span of nearly two years, openldap updated their autotools exactly once, while configure.in changed six times (with several additional intervening changes in-between consecutive releases). Which busy project would you like to repeat this experiment with? pgpnwz4eXNkq9.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Kevin Kofler writes: What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what rediffing means for us Fedora packagers), is more likely to break for configure.ac than for configure. And that's exactly what I said. Thank you for agreeing with me, that fixing configure is less likely to cause problems in the long run. That's just because I made a mispaste. ;-) So let's try again: What he was talking about is that rediffing patches, i.e. making patches apply to a new upstream version (that's what rediffing means for us Fedora packagers), is more likely to break for configure than for configure.ac. And I already pointed out why this is not true, several times. Furthermore, one part of your argument is that it is supposedly true because most changes to configure are due to autoconf getting updated, rather than any actual changes to configure.ac. In my last message, rather than speculate I posted logs from a randomly chosen project, openldap, that showed that to be not the case. I don't really have enough spare time to try downloading all releases, over the course of two years, of one project after another, trying to cherry-pick my example. Openldap was the first one that came to mind. I am confident that I am right, on this topic, so it was fairly likely that openldap's tarballs would've proved my point. They did, and you ignored it. I invite you to find a counterexample, but I regret to inform you, finding one won't be easy. Your other argument is that a patch to configure is less likely to require manual rebasing after configure changes, rather than an equivalent one to configure.ac, because new versions of autotools end up generating major changes to configure. Well, I just showed that routine changes to configure.ac occur far more often than updated to autoconf. Furthermore, as I pointed out, changes to nearby lines in configure.ac result in corresponding changes to configure being hundreds of lines apart, therefore a change to configure.ac is going to require rebasing of any patches to nearby lines, while the equivalent change to configure (once again -- for those with a short attention span -- that's a real patch to configure, and not a change to configure.ac, a regenerated configure, and a diff against the original version of configure) will therefore still apply, at most with some fuzz, and can therefore be rebased automatically. Conclusion: given a patch to configure.ac, and a patch to configure, an update to autotools is far likely to require more work to maintain the configure patch, while an update to configure.ac will likely require more woth main the configure.ac. And, this is the most likely outcome given, as I pointed out in openldap's case, which you would like to ignore, happens far more often than autotools update. Case closed. pgpYgOhWTHr3Z.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: In my last message, rather than speculate I posted logs from a randomly chosen project, openldap, that showed that to be not the case. That's one project. It doesn't prove any sort of a general trend. That's one more project's worth of data that you posted yourself. I invite you to find a counterexample, but I regret to inform you, finding one won't be easy. I already mentioned a bunch of counterexamples (all the stuff I worked on with Romain Liévin: tfdocgen, libticables2, libticonv, libtifiles2, libticalcs2, TiLP 2, TiEmu, TiLP GFM, TiEmu SkinEdit etc.). Rattling off a bunch of project names is a poor substitute for posting two years' worth of data. Why don't you grab the last one or two years' worth of these projects' releases, and see how many releases had updated configure.ac scripts, and how many releases were rebased to newer versions of autoconf. You know, like what I did, for openldap. But, I'm pretty sure I know what you'll expect to find. And you know the same thing, too. And which is why you don't want to do it. Well, I just showed that routine changes to configure.ac occur far more often than updated to autoconf. You just found one project which is extremely reluctant to upgrade their autoconf (and it's one of those projects still using the deprecated configure.in file name, that says pretty much everything). No, it means that there is absolutely no reason to rename a file, just for the heck of it. Whether it's configure.in or configure.ac, it's irrelevant. Or, perhaps, you'd like to explain the major difference between naming the source file for autoconf as configure.in, or configure.ac. And I didn't really do much of finding, as I said. It's one of the packages that I'm tracking on http://manpages.courier-mta.org which has the largest archive of historical releases. But, you're demanding to look at some project that uses configure.ac? Sure. Not that it makes one fig's worth of difference, of course, whether it's configure.in or configure.ac, but here you go: pcre. It's another one that I'm tracking. Upstream only has the last four releases available, but they also span about a year and a half chronologically, rougly the same time span as openldap: pcre-7.6/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.6. pcre-7.7/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.7. pcre-7.8/configure:# Generated by GNU Autoconf 2.61 for PCRE 7.8. pcre-7.9/configure:# Generated by GNU Autoconf 2.63 for PCRE 7.9. Looking at pcre's configure.acs, only pcre-7.8 had no substantive changes from the previous version, all the others contained very major changes. Looks like this one doesn't agree with your theory, too. So go ahead, and tell me again how that's still insufficient data for your liking (all the while offering zilch of hard data yourself, I note). I'll be happy to continue, as long as you like, but, you must understand, the hits will just keep on comin'. I also snuck a peek at the evolution of GnuTLS's toolchain. I guessed that it would be your best hope of salvaging some crumb of hard data that goes your way -- given that it's a GNU project and thus would be the most likely ones to always rebase to the latest-and-greatest autotools. Well, I looked at it, and would you like to see how GnuTLS's version history actually is? I'll be happy to post it. All you have to do is ask. Conclusion: given a patch to configure.ac, and a patch to configure, an update to autotools is far likely to require more work to maintain the configure patch, while an update to configure.ac will likely require more woth main the configure.ac. And, this is the most likely outcome given, as I pointed out in openldap's case, which you would like to ignore, happens far more often than autotools update. I'm ignoring your example because it's one example against 9+ examples from me, You did not post a single example. Rattling off names of packages is not the same thing as actually listing which version of autoconf generated each version, and how many original changes went into the corresponding configure.in (or configure.ac), thus giving you an actual look at what the rate of change is to configure.ac, versus the rate of change to the version of autotools that generated the configure script. Why don't you do that, and really prove how wrong I am? pgpEYVdID5iw6.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Which, as I pointed out, is still the case if you were to patch configure.ac instead. But, go ahead and ignore this inconvenient fact, too. As I explained (and you ignored), configure.ac tends to change a lot less between upstream releases, especially with a lot fewer irrelevant changes This may come as a shock to some, but configure does not often change unless configure.ac changes too. So, I'm not sure what does the frequency of changes to configure.ac has to do with anything. like line number changes or changes in aclocal snippets (because upstream WILL regenerate the file, not surgically edit it!), so it's a lot less likely to produce fuzz. 99% of the time when configure changes, it's due to changes in configure.ac. If someone thinks that by patching configure.ac, instead of configure, one achieves tremendous savings in the frequency of needing to rebase one's patches, they're in a desperate need for a reality check. Furthermore, changes to configure.ac will more likely to result in a more frequent manual rebases, where the corresponding changes in configure are far more likely to result in much simpler rebasing that's limited only to eliminating the fuzz. If one patches a line or two in configure.ac, then if the upstream futzes around with a neighboring line, the patch is going to get kicked out, and must be manually rebased. On the other hand, if a corresponding patch was against configure, instead, (and by that I mean a real patch, and not a patch to configure.ac followed by autoconf followed by a diff of the new configure against the old, I hate to explicitly say this, but some folks around here have a mental block on this subject, and can't wrap their brains around the concept of patching configure directly), the corresponding differences in configure would've ended up being hundred of lines apart, resulting in nothing more than some fuzz, that can be automatically updated. pgpbG99x7a1w7.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Sure, why not. It just so happens that, not too long ago, I was in an analogous position where I had some other package that also built against zlib, for $dayjob$. At $dayjob$ we also package free software using a scripted reproducible build. Not RPMs, but an analogous process, and at $dayjob$, for reasons that are irrelevant, zlib was installed into a nonstandard location. In CMake, in such a case, you just have to use: -DCMAKE_PREFIX_PATH=path It can also be exported as an environment variable. Either way, no changes to the scripts needed at all. That's great, and if this discussion was about cmake, then this would be a valid point. But, this thread is not about cmake. pgp9LwS4uDA9K.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Mark McLoughlin writes: On Tue, 2009-07-07 at 07:14 -0400, Sam Varshavchik wrote: libguestfs is a case in point - the Debian maintainer builds it from git using some unknown version of autoconf, and I build it on RHEL and This is a rare exception. No, it's a rare exception for project to keep autotools generated files in version control. Yet people still build lots of projects from version control on a variety of different distros using different versions of autotools. I'm sure that there are some folks who do that. But, the overwhelming majority of folks want to compile some stable result, rather than the greatest and the latest, which may not even compile at all. Presumably, those who want to build straight out of the upstream repo, have sufficient skills and experience to deal with autotools. I'm also making the point that maintainers build tarballs without paying much attention to the versions of autotools they're using. I don't get that impression. When I end up upgrading, as a result of the entire distro upgrade, or otherwise, to a new autotools, I make sure that I go through my existing configure scripts with a fine-toothed comb. Every time this happens I always end up tweaking something, making sure to replace obsoleted macros with their replacements, etc… But I can only speak for myself. pgpthrzT7i0BG.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: http://www.fsf.org/news/dont-depend-on-mono
Matthew Woehlke writes: Rui Miguel Silva Seabra wrote: In a couple of years Microsoft is bought by Fu-Bar Inc and there goes the promise down the drain. ...if only. The odds of *any* company that might buy out M$ (well, if it isn't started by Gates and/or Ballmer and/or such) being as bad as M$ have got to be pretty high ;-). If you want legal advice, pay a lawyer. This is not legal advice. Microsoft's statement is what's generally called covenant not to sue. When someone buys a business, they buy all the business's assets and liabilities. A covenant not to sue is generally considered a liability, and the covenant not to sue does not get to repudiated just by the virtue of the company changing owners. Having said all that -- I agree that MSFT's promise is not to be given much weight. If MSFT desired to sue someone, I'm sure they'd come up with some way to claim that their cause of action falls outside the scope of this covenant. They have plenty of money to pay lawyers to invent creative arguments, and it will be up to the defendants to prove that MSFT's covenant applies, in their defense. Even better, they'll just get sued for some other reason, like MSFT claiming that they're violating some patent in Windows, and it's just purely by accident, heavens to betsy, that they have a bunch of Mono-based products. Nothing to see here, move along. pgpOZtrszlIHV.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: This may come as a shock to some, but configure does not often change unless configure.ac changes too. So, I'm not sure what does the frequency of changes to configure.ac has to do with anything. Where your argument falls apart is that patch fuzz is a local concept! It's irrelevant that the file is not byte-identical. What matters is whether the context lines directly above and below the line(s) you're patching changed. And that's a lot more likely to happen for configure than for configure.ac. Wrong, as usual. Since each autoconf macro typically expands out to hundreds lines of shellcode, with the autoconf macro's parameter embedded somewhere in the middle of all that stuff, were you to change a parameter to an autoconf macro in configure.ac, and upstream changes the parameter in the next line, your patch gets broken. If the corresponding line in configure ended up getting patched, instead, your patch would still apply, with fuzz, since the results of upstream's changes would be hundreds of shellcode lines away. The patch would still apply. Even if the upstream deleted the preceding, or the succeeding, macro altogether, your patch to configure would still apply, since it patches one line in the middle of several dozens of lines of shellcode, and patch(1) is likely to search for the necessary fuzz. If someone thinks that by patching configure.ac, instead of configure, one achieves tremendous savings in the frequency of needing to rebase one's patches, they're in a desperate need for a reality check. No, they're just more familiar with how patch(1) works than you. Yes, tell me again how conflicting patches to neighboring lines in configure.ac works, while the equivalent two patches hundreds of lines apart in configure do not. Furthermore, changes to configure.ac will more likely to result in a more frequent manual rebases, where the corresponding changes in configure are far more likely to result in much simpler rebasing that's limited only to eliminating the fuzz. If one patches a line or two in configure.ac, then if the upstream futzes around with a neighboring line, the patch is going to get kicked out, and must be manually rebased. On the other hand, if a corresponding patch was against configure, instead, (and by that I mean a real patch, and not a patch to configure.ac followed by autoconf followed by a diff of the new configure against the old, I hate to explicitly say this, but some folks around here have a mental block on this subject, and can't wrap their brains around the concept of patching configure directly), the corresponding differences in configure would've ended up being hundred of lines apart, resulting in nothing more than some fuzz, that can be automatically updated. Huh? It's quite the opposite, as those hundred (sic) of lines which are inserted automatically (i.e. which do NOT come from configure.ac) are the ones most likely to change, Perhaps you should actually familiarize yourself with how most autoconf macros work, before you attempt to engage in a deep philosophical discussions on their merits. Stuff like AC_PATH_PROG produces several dozens lines of canned shellcode, with the arguments to AC_PATH_PROG appearing once, in the middle of them. Changing the parameter to AC_PATH_PROG, for example, does not change hundreds of lines of shellcode. This may come as a shock to you, but it does not. pgpznDS09s2gI.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: That's great, and if this discussion was about cmake, then this would be a valid point. But, this thread is not about cmake. That CMake has this feature implies that the autotools suck for not having it and forcing you to patch the configure script for your usecase. Indeed. Here's an idea -- why don't you mass mail the maintainers of all the autotools-using projects you can find on Sourceforge, and be sure to tell them how much autotools suck, and how better CMake is. I'm sure they will appreciate your helpful suggestions. pgpiWx886IclL.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: I don't get that impression. When I end up upgrading, as a result of the entire distro upgrade, or otherwise, to a new autotools, I make sure that I go through my existing configure scripts with a fine-toothed comb. Every time this happens I always end up tweaking something, making sure to replace obsoleted macros with their replacements, etc… But I can only speak for myself. Indeed. I can also only speak for myself, but I just run autoreconf -i -f and ignore all the warnings on the autotools-using projects I inherited. That's definitely a useful tip -- always ignore warnings. They are always completely meaningless. You don't need to worry about them. pgpLRK1x5WNq0.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: How exactly would that violate the GPL? You aren't patching the actual source code. Oh, no! You mean, the tarball I downloaded from upstream, labeled source code, did not actually contain the source code? Looks like I've been snookered. pgpXTa79FQv04.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Adam Jackson writes: On Sun, 2009-07-05 at 18:50 -0400, Sam Varshavchik wrote: Richard W.M. Jones writes: On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote: What line number changes? You cut a patch against configure, and you're done. That's it. And you get a big patch containing line numbers. Here's a single line change to configure.ac, and the corresponding patch that generates: == Who said anything about patching configure.ac? The cited link is not a patch to the configure script, it's a result of a patch to configure.ac. I'll repeat again: patch configure, not configure.ac. I said patch configure, and you reply, well, it won't work because if you patch configure.ac, run autoconf, then generate the patch between the original configure, and the new configure, I get a big hairball. Duh. The fundamental problem with patching configure instead of configure.ac (or Makefile instead of Makefile.am) is that it's changing the wrong semantic level. As was discussed previously in this thread, when creating packages the objective is not to patch the correct semantic level. If there's a problem that prevents the source from getting built properly, it's my understanding that the objective is to fix it in the way that absolutely minimizes the chance of accidentally introducing a side effect that creates a new problem that did not exist before. Whatever you would like the upstream to do for the next release, is a separate task. It may or may not be the same thing. So, the choices are, once it's identified where configure goes wrong are: 1) Fix the configure script, with shellcode whose contents are well understood 2) Patch configure.ac, and feed it to a code generator that spits out a brand new configure script. Your turn. Of course, if you take #2, you would, of course, verify which specific version of autoconf the upstream used, and whether the differences between your's and upstream's autoconf does not have any other impacts on the configure script. pgpN4f3tYdE61.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Oh, no! You mean, the tarball I downloaded from upstream, labeled source code, did not actually contain the source code? It contains both the actual source code and some unreadable generated gibberish which is NOT source code and which is being passed off as such Just because you can't read it, it's not gibberish. Besides, Merriam-Webster defines source code as: http://www.merriam-webster.com/dictionary/source%20code a computer program in its original programming language (as FORTRAN or C) before translation into object code usually by a compiler You learn something new about configure scripts every day. I didn't know that gets translated into object code, before execution. (which is why the autotools are broken by design: it's a mistake to encourage shipping generated files in a source tarball). Oh, ok. Good luck with your quest to change the mind of everyone who uses autoconf, to do it your way. Perhaps you'd like to show everyone how it should be done. Pick just one moderately popular package, convince them to let you own release management, then start releasing tarballs without a configure script. Let us know how it works out, but kindly give advance warning. I want to stock up on earplugs. pgpNmOIm5yfN0.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Just because you can't read it, it's not gibberish. It's not that *I* can't read it, it's that it is just plain hard to read, especially because it contains workarounds for bazillions of broken proprietary *nix shells (trying to use Bourne-style shell code as a portable language is a major design failure of its own, there are tons of subtly different dialects and megatons of plain bugs). Try reading that 1.1 MB (!) shell script: http://svn.calcforge.org/viewvc/emu- tigcc/trunk/configure?revision=2861root=emu-tigcc It's generated from a 9.7 KB configure.ac: http://svn.calcforge.org/viewvc/emu- tigcc/trunk/configure.ac?revision=2847root=emu-tigcc Sure, why not. It just so happens that, not too long ago, I was in an analogous position where I had some other package that also built against zlib, for $dayjob$. At $dayjob$ we also package free software using a scripted reproducible build. Not RPMs, but an analogous process, and at $dayjob$, for reasons that are irrelevant, zlib was installed into a nonstandard location. The fix for that, and the analogous fix here, were that to be the case, was to stick CPPFLAGS=-I path $CPPFLAGS right after the following line in configure, grep for it: # Check for zlib I'm of course, skipping over some other details (similar thing needs to be done with LDFLAGS). So, you see -- it's not really complicated. Not at all. And, this is a typical reason why one might need to fix up the configure script. In at least 99%+ of the time Perhaps if it's necessary to do major surgery on some package's configure script, for some reason -- if wholesale changes are required -- one might have an argument for patching configure.ac (or configure.in, for us old-timers), and rebuilding configure. But for 99% of the actual use case situations out there, it's like driving in a 1 nail with a sledgehammer. Too much risk for collateral damage. And in fact KDE did just that (they moved to CMake and nobody at KDE is missing the autotools, quite the opposite!) and several other projects followed suit. Yes, well, that might be one of the reasons why KDE is sweeping over the Linux desktop, and Gnome is just a fading memory for most. pgpzwhKdz6wsh.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: Gee, I didn't know that rediffing is a mandatory step. It is when your patch no longer applies after you upgraded the package to a new upstream version. Which, as I pointed out, is still the case if you were to patch configure.ac instead. But, go ahead and ignore this inconvenient fact, too. pgpvNRhrj6Uyw.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Peter Gordon writes: On Mon, 2009-07-06 at 21:24 -0400, Sam Varshavchik wrote: Yes, well, that might be one of the reasons why KDE is sweeping over the Linux desktop, and Gnome is just a fading memory for most. Please don't claim such obviously fallacious things. Like it or not, GNOME has been - and continues to be - the default desktop environment on a great many major GNU/Linux distributions (including Fedora). Yes -- I plead guilty. I often forget to put explicit sarcasm tags in the right places. Perhaps you might want to reread my entire message. pgphGU0G2GdfW.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Richard W.M. Jones writes: There's been lots of previous discussion of this silly idea of patching generated code. You end up carrying enormous patches containing just line number changes that often can't be applied upstream, and can't be carried forward to new upstream releases -- What line number changes? You cut a patch against configure, and you're done. That's it. When a later release rolls down the pike, the patch gets rebased, and fixed up, against a newer version. I fail to see any substantive difference between that, and patching any other file in the source tarball. With a subsequent release, you'll still have to rebase your existing patch, if the new release did not fix the original bug. As I understand, rpm's default settings now reject fuzz in patch files, so you'll just have to do it, now. And since the likelyhood of configure changing in a new release is no different than any other source file getting changed, on average, believing that some work can be saved just by choosing to patch a different file, then the one that really needs to be patched, is somewhat naive. what on earth use is that? And still no one has explained coherently why the sky will fall if we patch configure.ac and Makefile.am and just rerun autoconf/automake in the specfile. Because autoconf and automake are going to change a lot more than just what the patch was intended to patch. It's fairly likely that the upstream is using a different version of autoconf and automake, so this ends up producing a brand new configure and makefile. If I were to do that, then I would find it necessary to spend additional time testing the new configure script, running it an eyeballing all of its voluminous output, watching for something that falls out, as a result of the new configure script. Dunno, it just seems much easier to me to just patch a single line in configure, adding or fixing some directory's name, then to do all that. I get the impression that there's a meme going around that patching configure is some kind of a herculean, impossible task, and that's its easier to patch configure.in, then run autoconf to generate a brand new configure script. I suppose that there may be some situations where rebuilding the configure script is the right thing to do, but I wouldn't expect to have this happen very often. pgpf9uyyPyAXC.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Conrad Meyer writes: On Sunday 05 July 2009 07:45:46 am Sam Varshavchik wrote: *snip* With a subsequent release, you'll still have to rebase your existing patch, if the new release did not fix the original bug. As I understand, rpm's default settings now reject fuzz in patch files, so you'll just have to do it, now. And since the likelyhood of configure changing in a new release is no different than any other source file getting changed, on average, believing that some work can be saved just by choosing to patch a different file, then the one that really needs to be patched, is somewhat naive. The problem is that configure scripts are not written by a human, but generated by autoconf. It is easy to make small changes to configure.ac and generate large changes in configure. This makes it easier to rebase patches against configure.ac. The macros in configure.ac generally expand out to canned shell script fragments, with the macro's parameters substituted somewhere. Changing a parameter in configure.ac usually results in an equivalent substitution in configure. Generally, only when one adds or removes entire macros from configure.ac, that's when this results in wholesale changes to configure. In my experience, the overwhelming majority of fixups to configure scripts involve nothing more than adjusting someone's pathname, or compiler flags. For this kind of scope, rebuilding the entire configure script is overkill, and I wouldn't do it unless I audit it and verify whether or not upstream is relying on some specific behavior in the specific version of autoconf that was used to build the original configure script. Patching the configure script is much safer than patching configure.ac, then have autoconf grok all .m4 macros and rebuild the whole thing, likely ending up with a completely different beast, that not only includes your changes but who knows what else. pgpN1vr9uZMWz.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Better ways to format USB disks (file fomats etc)
Andreas Tunek writes: Maybe I should clarify my use case experience. After I used GParted to format the HDD to ext3 (and ext4 later) I tried to create a folder on the HDD. I could not do this as a normal user, only as root. When I formatted the HDD to ntfs I could create folders and files. I want the ntfs behavior. Create a top-level folder on the USB drive that's owned by your userid, then you can create any subfolders that your heart desires. pgpuVIvPBjMSm.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Richard W.M. Jones writes: On Sun, Jul 05, 2009 at 10:45:46AM -0400, Sam Varshavchik wrote: What line number changes? You cut a patch against configure, and you're done. That's it. And you get a big patch containing line numbers. Here's a single line change to configure.ac, and the corresponding patch that generates: == Who said anything about patching configure.ac? The cited link is not a patch to the configure script, it's a result of a patch to configure.ac. I'll repeat again: patch configure, not configure.ac. I said patch configure, and you reply, well, it won't work because if you patch configure.ac, run autoconf, then generate the patch between the original configure, and the new configure, I get a big hairball. Duh. I've been reading configure scripts long enough to know that your pseudo-patch is the result of adding AC_PATH_PROG(PERL, perl) to configure.ac. Now, why don't you explain why, and we'll go from there. Presuming that this is needed because some script in $srcdir uses the PERL environment variable, or a later part of the configure script itself (it assumes that PERL is set in the environment) then I would just patch in: PERL=/usr/bin/perl export PERL instead, to configure. Or, have the spec file set PERL itself, before running configure. If the reason for the patch is that there's some *.in in src with a @PERL@ placeholder, I'd just patch that *.in file directly, instead. No need to uselessly screw around with configure, when I don't even need to do it. Like I said earlier, there seems to be a meme going around that making a minor fix to configure is an impossible task. It can't be done, the only option is to fix configure.ac, and rerun autoconf. configure itself is untouchable. You can't patch it, you have to patch configure.ac, and then regenerate it. pgpsMenneXc0f.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Richard W.M. Jones writes: On Sun, Jul 05, 2009 at 02:24:43PM -0400, Sam Varshavchik wrote: For this kind of scope, rebuilding the entire configure script is overkill, and I wouldn't do it unless I audit it and verify whether or not upstream is relying on some specific behavior in the specific version of autoconf that was used to build the original configure script. So to make this patch, I've got to track down the exact version of all the autotools that upstream happens to be using. Great. If you want to patch configure.ac, and then rerun autoconf to generate a brand new configure script, then, yes, that's what due diligence indicates. But that's what /you/ want to do, not me. Me, I'll just apply a patch to the configure script, directly. pgpmwaDCZCPFb.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Orcan Ogetbil writes: On Sun, Jul 5, 2009 at 2:24 PM, Sam Varshavchik wrote: [cut] Patching the configure script is much safer than patching configure.ac, then have autoconf grok all .m4 macros and rebuild the whole thing, likely ending up with a completely different beast, that not only includes your changes but who knows what else. What else? You and some other people are defending this from the beginning of this thread but no one explained what else might change. If I patch configure.ac and Makefile.am, then run autotools and build the RPM package that way, what else might go in unnoticed? Why are you asking me? I'm the one arguing against patching configure.ac and Makefile.am and rerunning autotools. Please back up your claims. I do not have much knowledge to make claims in either direction but I am willing to learn. You can start by reading this thread, again. pgpcbfXT9Uu4O.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Sam Varshavchik wrote: But that's what /you/ want to do, not me. Me, I'll just apply a patch to the configure script, directly. And you'll be violating the GPL (unless you're talking about a BSD-style-licensed software or configure.ac is explicitly marked with special permissions). The GPL requires you to edit the preferred form for modification, which is definitely NOT a generated file. You do not understand the GPL. pgprL4RNac6LY.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Toshio Kuratomi writes: On 07/04/2009 03:22 PM, Richard W.M. Jones wrote: On Wed, Jul 01, 2009 at 12:40:44PM +0200, Ralf Corsepius wrote: No, not if they bundle the generated auto* files with their tarballs, as they are supposed to do. They're not supposed to do that. Don't make stuff up. It's true there are no literal files matching the wildcard auto* that are generated for inclusion in the tarballs. But I think Ralf is talking about the files generated by the auto-tools (autoconf, automake, and libtool). Those are supposed to be bundled with the tarballs. And, they are. So, the automake update should not really have any impact on rebuilding any existing well-made rpm package. The only possible impact would be to those packages that rerun automake or autoconf, for some reason. Although I do believe that there's a small number of rpms whose spec script does that, I really think that this is not correct, and the packaging guidelines should really prohibit that. If the configure script needs patching, make a patch against the configure script, and/or Makefile.in; rather than patching configure.in and Makefile.am, and rerun all the auto scripts. pgpeWfZkWM1QT.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Stepan Kasal writes: Hello, On Tue, Jun 30, 2009 at 06:58:39PM -0400, Sam Varshavchik wrote: Kevin Kofler writes: Some software may need the new version to build. Then, they need to be patched so that they would get built for F9, or they should not be built for F9 altogether. I'm afraid the answer shows you do not fully understand the context. Sorry, I understand the concept very well, and have done precisely that numerous times before. pgpuiFk57vFWp.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
Kevin Kofler writes: Daniel P. Berrange wrote: This is seriously dubious for F9, since if it causes a problem there is next to no time in which to fix it before F9 updates are turned off. In general I struggle to believe that there is a compelling need to rebase automake versions in our stable releases. Some software may need the new version to build. Then, they need to be patched so that they would get built for F9, or they should not be built for F9 altogether. pgp5bf8cXm7l4.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: update mechanism for new releases
Martin Langhoff writes: On Tue, Jun 23, 2009 at 10:33 PM, Seth Vidalskvi...@fedoraproject.org wrote: they're not insolvable - they are just very very very hard. :-) At the end of the day, if the OS doesn't give you atomic multi-file transactions, and your %pre/%post scripts aren't also written perfectly atomically, I would say that it _is_ impossible. If the %pre/%post scripts are not atomic, it's impossible. However, atomic multi-file transaction support from the filesystem is not necessary. That part is perfectly solvable. pgpfPhDHNWLhy.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
