Re: Bug#367962: Please don't ship a /lib64 symlink in the package on amd64
* Aurelien Jarno ([EMAIL PROTECTED]) wrote: The FHS is actually not very clear, as it says 64-bit libraries should be in (/usr)/lib64, whereas system libraries should be in (/usr)/lib. This is a contradiction for a pure 64-bit system. The FHS is very clear about the path to the 64bit linker, and that goes through /lib64, getting rid of that isn't an option. - I am not sure that creating the link in postinst will work. Creating it in preinst looks safer to me. I'd be a little nervous about creating it in postinst too, honestly. - If you can install files in (/usr)/lib64, the files will end up in (/usr)/lib. And dpkg won't know anything about them. dpkg -S and other tools won't work correctly. Yeah, I'm not sure it really makes sense to need to install into both... It would have been much more useful for you to include the *reasoning* behind Goswin's request rather than just your reasons for not wanting to do what he's asking. - If you have two packages providing the same files in (/usr)/lib and (/usr)/lib64, then the files will be overwritten without warning. This is IMHO not acceptable. My guess is that his intent was actually to allow *seperate* packages to install into either /lib or /lib64 on a package-by-package basis. This might resolve some bugs in packages which, when they detect they're being compiled for amd64, default to installing into /lib64 instead of /lib. Personally I think that's something that just needs to be dealt with and those packages should be fixed but that's my guess as to where the question came from. It's also possible a given package wants to install some things in /lib64 (say, actual libraries) and other things in /lib (say, helper programs, ala blah-config). Could you please give me your opinion on that, so that I can take a decision? The link itself certainly can't go away. I'd be more inclined to say progams on a pure 64bit platform shouldn't install into /lib64 than to have some things installing into /lib and others into /lib64. Part of this comes from the concern that this will bring out other bugs in packages where having this distinction might cause overlaps as mentioned above. Thanks, Stephen signature.asc Description: Digital signature
Re: amd64 CD builds
* Steve McIntyre ([EMAIL PROTECTED]) wrote: At the moment the regular CD builds for amd64 are still using the separate amd64 archive from ftbfs.debian.net. As amd64 is about to hit testing in the mainr archive Real Soon Now, I'm planning on moving the CD builds over to use the normal archive this weekend. Does that sound reasonable? I don't believe grub is in the main archive yet... Thanks, Stephen signature.asc Description: Digital signature
Re: Uml, vserver or xen for virtual servers?
* Jacob S ([EMAIL PROTECTED]) wrote: Now that I have Sarge installed on my amd64 box, I was wanting to install some virtual servers on it. But I notice that the AMD64 port of Sarge doesn't have all of the packages needed for any of the virtual servers listed in the subject of this e-mail. eh? util-vserver is in the amd64 archive and works just fine for me. There aren't kernel packages, that's true, but also not that big an issue, imv. It does depend on what you want to do but I've found vservers work very well for what I'm doing. Enjoy, Stephen signature.asc Description: Digital signature
Re: Uml, vserver or xen for virtual servers?
* Jacob S ([EMAIL PROTECTED]) wrote: And what would the both of your be doing with your vservers? (Just trying to educate myself a little bit more about the differences between Xen, UML and Vserver.) Isolating services into seperate areas (better chroot). Enjoy, Stephen signature.asc Description: Digital signature
Re: Adding tg3 into a 2.6.12 kernel
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: On Sat, Jul 23, 2005 at 10:14:07AM -0400, Stephen Frost wrote: * Peter Yorke ([EMAIL PROTECTED]) wrote: From: Johan Groth [mailto:[EMAIL PROTECTED] When I installed linux-image-2.6.12-1-amd64-k8-smp, it was already there Have we got a d-i that works w/ this image? I'd really like to get my hands on one if we do... :) I just finished building one. Now I just have to test it (minimally at least). Great! If it works can you post it somewhere? :) Thanks, Stephen signature.asc Description: Digital signature
Re: Adding tg3 into a 2.6.12 kernel
* Peter Yorke ([EMAIL PROTECTED]) wrote: From: Johan Groth [mailto:[EMAIL PROTECTED] When I installed linux-image-2.6.12-1-amd64-k8-smp, it was already there Have we got a d-i that works w/ this image? I'd really like to get my hands on one if we do... :) Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* Bob Proulx ([EMAIL PROTECTED]) wrote: Goswin von Brederlow wrote: Hugo Mills [EMAIL PROTECTED] writes: How? You can't install your two multiarch versions of libvorbis without a hacked package manager that understands how to do it. You name packages lib32foo and lib64foo or something non conflicting. Or you use the multiarch patch for dpkg. I really don't like needing to change the package names to be uniquely named. I think for multiarch to really work in Debian then dpkg needs to have a split brain where the architecture specific packages are tracked separately. I think that's what Goswin was saying (Or you use the multiarch patch for dpkg.). I thought the original idea was to have the package names be the same actually. I don't know that it'd be a big deal either way though. Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: On Tue, Jul 05, 2005 at 04:46:59PM -0400, Stephen Frost wrote: What's the reason for having both versions of a given app installed? I'm pretty sure it was decided that was a bad idea and that there wasn't any good use case for it and so we weren't going to try and support it. It just doesn't make sense. I want to play with 64bit firefox so i can develop a 64bit plugin for it. I might at the same time want 32bit firefox so I can use plugins that are still 32bit only. That's just one reason. And a rather unlikely one at that. Repeat for mplayer where some codecs are 32bit only for now, but others might run much faster in 64bit and you want to help port it there. So you're going to have your own source code which you're going to be developing with and building. Sorry, I think you'll just have to manage on your own in this case (I mean, really, you're almost certainly going to be doing all of this outside of the existing packaging system *anyway*). I don't think it's sensible or useful to attempt to support having a 32bit and a 64bit version of a given app installed in the packaging system. Your example above doesn't even illustrate a reason to support it. This is only an issue with libraries, and /usr/share should have things which are arch-independent and /usr/lib/blah should have arch-dependent things. If packages don't follow that today then they're broken already and need to be fixed. It is true that there can't be multiple things installed with files in the same place, so any /usr/share usage in libraries needs to be split out in a -common package for that library. This isn't an issue for programs because we're not interested in supporting the unjustified case for having the same program both 32bit and 64bit at the same time. If we don't then I consider multiarch very broken. That's nice. Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: On Tue, Jul 05, 2005 at 07:54:06PM -0400, Stephen Frost wrote: apt-get install A::amd64; Should automatically uninstall the i386 version of A and install the amd64 version. If that's how it is going to behave, I will stick with a chroot for 32bit. Much more useful then. I do have reason to want both the 32 and 64bit versions of a program. I think many people do, especially developers but also users. Developers are unlikely to use the packaging system in the few cases you've described. You havn't given any reason why a user would have any use for it. There are quite a few reasons why trying to do such would be very, very ugly and would undoubtably cause problems for both users and developers. Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: On Tue, Jul 05, 2005 at 03:04:56PM -0400, David Wood wrote: What's the problem? Yes, it will take work to _finish_, but why haven't we even _started_? Many packages/programs have hardcoded paths in them which will look in /usr/lib and not in your new directory. Then they're busted and need to be fixed. Also not at all compatible with existing software on any architecture. This is just plain false. Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: On Tue, Jul 05, 2005 at 03:21:41PM -0400, David Wood wrote: I'm just trying to understand what people's objections to multiarch are. I didn't understand what Hugo said in answer to that. I meant that it sounded like his answers (the problems he brought up) were things that multiarch would fix, not problems with multiarch itself. The main objection is to change locations of files in a way that is incompatible with existing software on linux. Pfft, give me a break. Guess we'll never move anything ever again. That's just not how it works. Would they not work properly with the symlink in place? is /usr/lib/i386-linux a symlink back to /usr/lib or what? /usr/lib can't be a symlink to /usr/lib/i386-linux after all. So if programs on i386 look for things in /usr/lib and programs on amd64 look in /usr/lib, which one gets to keep the location and which one MUST move? Actually you can put a symlink in /usr/lib to the actual library in /usr/lib/i386-linux, if necessary. Sure you can recode ld-linux.so to look in /lib/arch and /usr/lib/arch which I have seen done years ago on solaris systems using various path lookup tricks and such. 'tricks' isn't exactly an appropriate word for this given that's how things are looked up today. And if that failed (is this really possible?), why not use a bind mount? Or a hard link? (Well, maybe you don't like hard links, but without multiarch, bind mounts in chroots are a fact of life anyway.) The problem is you have multiple architectures that all want the same filenames in the same location. bind mounts and symlinks won't solve that unfortunately. Changing the ld loader might, but even then anything else that has a hardcoded path needs fixing. That'd be why we need multiarch, yes. The symlinks can be used to solve the problem when you can be sure of the answer, and as I recall there was a proposal to have a 'default' for the system which would answer the question when there's multiple options on the system. I feel a little crazy here. Is there something really basic I'm missing? What do you mean not compatible? With the linkage of the legacy directory to the new one, where would the incompatibility come from? Both amd64 and i386 programs want the legacy location. They can't both be symlinks. And if you place the arch stuff as a subdir of the original location it can't be a bind mount or symlink at all. You can certainly have a symlink from /usr/lib/libx.so.1 - /usr/lib/i386-linux/libx.so.1, and if you have to pick one when there's multiple options available then you'll just have to pick one and that's life. Generally things that require this kind of hackery should be fixed regardless. A library would work unmodified in the old location, and then over time it can be modified to work in the new one. But is the old location file going to be i386 or amd64 architecture? Depends on the 'default' setting of the box. Some other distributions have made their amd64 stuff use /usr/lib64/ instead, which we are compatible with using a symlink, but it's considered a rather unclean solution by many. Right, which is why there's multiarch... Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* Lennart Sorensen ([EMAIL PROTECTED]) wrote: Of course there is also the issue of how to deal with calling the 32 or 64bit version of program x if you have both versions installed. Perhaps a helper tool to say run64bit version of x would deal with that, and your idea of having symlinks in the original location to a default version would deal well with that. If not specified you run the one that has the symlink. What's the reason for having both versions of a given app installed? I'm pretty sure it was decided that was a bad idea and that there wasn't any good use case for it and so we weren't going to try and support it. It just doesn't make sense. Of course then there is things like data files in /usr/share which are not architecture specific. If you install the same version of both 32 and 64bit for a package, then the files should match and just keeping one copy should be fine. If for some reason you install a different version of one of them (as would happen during upgrades) how do we resolve those files? They aren't always seperated into an architecture all package (which would of course be trivial to handle). Do we divert the files from the older version somewhere, and then remove it when the older one is upgraded to match the newer one? No point wasting disk space on identical files after all. This is only an issue with libraries, and /usr/share should have things which are arch-independent and /usr/lib/blah should have arch-dependent things. If packages don't follow that today then they're broken already and need to be fixed. It is true that there can't be multiple things installed with files in the same place, so any /usr/share usage in libraries needs to be split out in a -common package for that library. This isn't an issue for programs because we're not interested in supporting the unjustified case for having the same program both 32bit and 64bit at the same time. Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* David Wood ([EMAIL PROTECTED]) wrote: On Tue, 5 Jul 2005, Lennart Sorensen wrote: Would they not work properly with the symlink in place? is /usr/lib/i386-linux a symlink back to /usr/lib or what? /usr/lib As I understand it, /usr/lib is a symlink/hardlink/bindmount to /usr/lib/i386-linux, not the other way around. I'd like to see that symlink. :) I am not saying that one starts multiarch and immediately pretends its finished. Only that one can start, without breaking anything... so why not start? This is true and I think we do need to start on it soon. I'm not sure about not breaking *anything*, but what does get broken needs to get fixed anyway. Why not make /usr/lib/i386-linux and make the links? New packages would eventually follow the new standard directly; old ones would be gradually ported over. The whole time, you are still pure64, or ia32. At some point, when dpkg/apt and the other infrastructure work is finished, and a usable subset of packages is compliant, then you can switch to being multiarch. In the meantime, you manage everything just as you do now. It'd probably be better to get multiarch support in the base packages first, but, eh. Right. But that's why you make the links, and then start on the work. Later, when the work is complete, we can support multiple architectures, and until then, we have lost nothing - everything works as it does now. Eh, I'd rather try to do without the symlinks to start and then see what breaks. :) Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* Latchezar Dimitrov ([EMAIL PROTECTED]) wrote: What's the reason for having both versions of a given app installed? I'm pretty sure it was decided that was a bad idea and that there wasn't any good use case for it and so we weren't going to try and support it. It just doesn't make sense. The only reason is to be able to run both of them at your discretion. apt-get install A::amd64; Should automatically uninstall the i386 version of A and install the amd64 version. Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* J?r?me Warnier ([EMAIL PROTECTED]) wrote: [..] As a start, does anyone know exactly how Solaris does, and can explain it to whoever is interested in learning about multiarch? Wouldn't that be interesting? It's basically biarch... I've got a couple Solaris boxes and I havn't seen much different between what it does and biarch. ie: Not what we're going for *anyway*, so... Thanks, Stephen signature.asc Description: Digital signature
Re: multiarch/bi-arch status (ETA) question
* Latchezar Dimitrov ([EMAIL PROTECTED]) wrote: Do you really do dfs any time you want to do anything on your computer? Yeah, that's *exactly* the same thing as daring to use apt-get... Thanks, Stephen signature.asc Description: Digital signature
Re: rsync mirrors?
* Goswin von Brederlow ([EMAIL PROTECTED]) wrote: From the master list I see only 2 US mirrors and only one with rsync; debian.csail.mit.edu ftp/http/rsync This mirror doesn't appear to allow rsync for debian-amd64... At least, it didn't work for me when I tried to use it. If someone has any more info about this I'd be very curious to know. :) Stephen signature.asc Description: Digital signature
Re: broken libnss-ldap
* Roman Hodek ([EMAIL PROTECTED]) wrote: However, for amd64 it seems that libpam-ldap has been compiled with an older libldap2 (probably because build dependencies weren't tight enough): The latest OpenLDAP should fix the libpam-ldap / libnss-ldap problems... I couldn't exactly have changed the libpam-ldap build dependencies to depend on something not yet in the archive. :) Please let me know if the problem persists with the latest libldap2 (and please get that into amd64 soon, if it's not already...). Thanks, Stephen signature.asc Description: Digital signature
Re: broken libnss-ldap
* Cyril Chaboisseau ([EMAIL PROTECTED]) wrote: I still have problems with libnss-ldap and the lastest version of libldap2 doesn't seem to solve it : What *specific* versions of things are you using? Can you also send the output of ls -l /usr/lib/libldap* ? Thanks, Stephen signature.asc Description: Digital signature
Re: broken libnss-ldap
* Cyril Chaboisseau ([EMAIL PROTECTED]) wrote: ...so I tried to recompile libnss-ldap version 238-1 linking with ldap_r but it didn't work either so I went back to libnss-ldap version 220-1 (which dates back to August 2004) and everything went fine again ! it could help me to report the bug in debian (weither it is a bug related to amd64 or not, this is yet another question...) I don't know how to trigger the bug in Perl (it really seems perl is the culprit here) Wait a minute. With the *latest* libldap2 and libnss-ldap 220-1, it *works*? Could you please confirm that? If that's the case and the only thing changing is libnss-ldap, then it may be an issue with libnss-ldap itself somehow... Thanks, Stephen signature.asc Description: Digital signature
Re: AMD64 archive move
* Joerg Jaspert ([EMAIL PROTECTED]) wrote: On 10278 March 1977, Stephen Frost wrote: * Joerg Jaspert ([EMAIL PROTECTED]) wrote: We also intend to offer a push-mirror service for interested mirrors, so if you are an interested mirror admin please contact me and I will come back to you with further instructions, as soon as we are sure our archive is clean. What about for private mirrors? Will rsync be available (as it was on alioth)? If so, what's the rsync URL so I can update my mirror scripts? :) It is generally available, just limited to 6 concurrent users as to many rsyncs can kill machines. (Well, this should be able to do more, but atm we have 6 :) So best is for users to wait a few days and use one of the mirrors that are nearer to them. Will there be a mirror which provides rsync, and if so which one? I don't mind using a seperate mirror for my rsync (I do currently for the main archive already). Thanks, Stephen signature.asc Description: Digital signature
Lack of NPTL and LD_ASSUME_KERNEL breakage
Greetings, So, pure64 doesn't have non-NPTL, fine, but can we make it so that setting LD_ASSUME_KERNEL=non-NPTL kernel doesn't break? It's rather annoying... It seems to me that glibc should probably just ignore LD_ASSUME_KERNEL (assuming it's only used for NPTL) when there aren't actually any options available besides NPTL anyway. Stephen signature.asc Description: Digital signature
Re: Still confused about pure64 package changelogs
* Javier Kohen ([EMAIL PROTECTED]) wrote: I guess he wants to know before installing the package. Synaptic has the feature he wants but, as he said, sometimes it takes a while (hours, days?) until some changelogs are updated. However, it usually works great and it was something many of us were hoping would be added to Debian. apt-listchanges shows you before the packages are installed and then prompts you asking if you want to continue installing packages or not... Stephen signature.asc Description: Digital signature
Re: Installation disks should be using 2.6.10 kernel
* brad ([EMAIL PROTECTED]) wrote: [EMAIL PROTECTED] wrote: That's exactly my point. The 2.6.10 is vastly superior to the previous kernel and should be elected as the kernel of choice for installation on amd64 motherboards (or at least, on motherboards with the nforce3 250). But, such netboot image don't exist at this time. I wondered how difficult it is to refresh the netboot ISO ? Sorry to jump in here in the middle. A 2.6.10 amd64 ISO would be nice but I've noticed at least one problem w/ 2.6.10 - grub segfaults on my amd64 box when attempting to install the stage2 boot loader under 2.6.10. It works fine under the 2.6.8 from the amd64 d-i ISO. Anyone else seen this or have any idea what's up with it? It's a Tyan motherboard, AMD-8111 using an LSI 53c1030 PCI-X Dual Ultra320 w/ an external SCSI hardware RAID array. I've got two partitions, a regular ext3 one for root and everything else on an LVM/DM partition w/ multiple LVs for usr, var, home, data. Stephen signature.asc Description: Digital signature
Re: Do I need 64Bit if RAM is more than 4 GB?
* Mattias Wadenstein ([EMAIL PROTECTED]) wrote: Even in 1995 4GB would have been a rather expensive amount of ram even for a high end sparc or power machine. Well, instead of searching for prices, go find an old manual of the largest sun sparc32 smp? The one I can think of right now is the ss1000, were there any bigger ones? Before the ultrasparc days that is. SparcCenter 2000, we had one here actually. 10 system boards, up to 2 procs each (as I recall we had 16 processors in ours), 0, 8 or 16 SIMMs per board which were 8M or 32M. I believe we had the 8 system boards that had CPUs full with 32M SIMMs for a total of 4G. I'm pretty sure the system was capable of going to 32 CPUs w/ the dual-CPU modules. I'm not sure if you could get more than 4G of memory in to it though. Stephen signature.asc Description: Digital signature
Re: amd64 and sarge
* Raul Miller ([EMAIL PROTECTED]) wrote: On Thu, Jul 29, 2004 at 09:53:56AM -0500, Pete Harlan wrote: Multiarch, bi-arch, some people want them, that's great, but they're simply offtopic with respect to the amd64 port. That said, the amd64 port can accomodate both without much problem. Bi-arch being less painful than multiarch, in my opinion -- it needs to touch far fewer packages: http://lists.debian.org/debian-amd64/2004/07/msg00244.html This is only true if you do a half-ass[1] job w/ bi-arch. This isn't, and never has been, the intent of the amd64 porters. Multiarch is coming and will take quite a while to do but we will be much better off for it. We will also give our users the ability to use their systems to their fullest potential- not just as a platform upon which to run binary-only commercial apps. Stephen [1]: Actually, that's giving it more credit than it deserves. It'd be no where *near* half, it'd be more like 1% of the packages. Pretty much a waste of time. signature.asc Description: Digital signature
Re: amd64 and sarge
* Raul Miller ([EMAIL PROTECTED]) wrote: I dispute your half-ass assertion. biarch is useful for systems in transition. That means people upgrading from 32 bit systems, and people working with packages which haven't been ported -- for whatever reason. The vast majority of packages in Debian have *already* been ported. That's what pure64 *is*. The number of people 'upgrading' from 32bit systems is probably around 1 (that being you), the rest of us have moved on to pure64 already, and did so a long ass time ago. There's little to no gain in making every package biarch. So there's no point in calling a plan to not do so half-ass. This is just blatently false. There certainly is gain in making every package supported on both architectures. It gives our users *options*. For the amd64 side, it allows programs (*all* of them) to use more than 2G of memory if they have a need to, it makes *most* of them run faster and more effeciently. We need the i386 stuff anyway since there are i386-only systems out there today. Perhaps some day we will be able to remove i386, but I don't expect that to happen anytime soon. And, frankly, the current pure64 port already includes most of what biarch needs. The current pure64 port has gone far beyond the half-ass biarch you're referring to. Unfortunately, you can't manage to see that. Stephen signature.asc Description: Digital signature
Re: amd64 and sarge
* Raul Miller ([EMAIL PROTECTED]) wrote: On Thu, Jul 29, 2004 at 12:34:33PM -0400, Stephen Frost wrote: That's what pure64 *is*. The number of people 'upgrading' from 32bit systems is probably around 1 (that being you), the rest of us have moved on to pure64 already, and did so a long ass time ago. If this logic were correct, no one would need to install amd64 in the future. This statement just doesn't make any sense. Maybe you can't imagine that people would replace a motherboard and keep the same hard drive, but that doesn't mean nobody works that way. People might do that, fewer people do that today than did it in the past but even so, people are likely to expect to need to reinstall in that case. Certainly if they do their research and they want to take advantage of the new motherboard/processor they've got they're likely to *want* to do a new install. This is just blatently false. There certainly is gain in making every package supported on both architectures. It gives our users *options*. For the amd64 side, it allows programs (*all* of them) to use more than 2G of memory if they have a need to, it makes *most* of them run faster and more effeciently. We need the i386 stuff anyway since there are i386-only systems out there today. Perhaps some day we will be able to remove i386, but I don't expect that to happen anytime soon. You're talking about optimization. If you're really concerned about optimization, you'd be talking about building and installing packages from source. That offers far more in the way of choices and tailoring. Uh, being able to access 2G of memory isn't what I'd consider an 'optimization'. Being able to access many more registers is closer to an optimization but it can be done for all cases, and will work on all amd64 platforms, and is much more likely to speed things up than slow them down. Regardless, however, I want the programs I install to be fast, effecient, and in some cases they'll need to address 2G of memory. That doesn't mean I want to compile them all myself, I sure as hell don't, that's why I use Debian, so I don't have to. My biarch proposal doesn't address how to make sure amd64 packages don't replace an i386 packages across upgrades of those packages, but that's because I don't care about that issue -- not because it can't be done. Uh, I'm not interested in making sure amd64 packages don't replace i386 packages. I've really got nfc where theis comment came from. The current pure64 port has gone far beyond the half-ass biarch you're referring to. Unfortunately, you can't manage to see that. False. First, in a very literal sense, the pure64 port is incorporated in the biarch I'm referring to. From what I saw, maybe a few bits and pieces of it here and there. Second, the changes I've proposed have obviously not been incorporated into pure64. That's because they're not necessary or useful. More fundamentally, half-assed is purely pejorative, and most of what you're saying is more about belittling than conveying useful information. It's half-assed because it's addressing only perhaps 1% of the packages in Debian. This is so that you can claim how 'easy' it is while making the assumption that no one will care that they're running i386 on their Opteron. Stephen signature.asc Description: Digital signature
Re: amd64 - x86_64
* Robert Millan ([EMAIL PROTECTED]) wrote: So your point is that dual namings are not that bad. Ok. Now, how is this dual naming actualy _better_ than the former scheme: DEB_HOST_ARCH = x86-64 DEB_HOST_GNU_CPU = x86_64 To my eyes, the former scheme was at least consistent. If your answer is that for some reason amd64 is preferable to x86-64, how is it the same reason does not apply to x86_64? amd64 is preferred for DEB_HOST_ARCH. DEB_HOST_GNU_CPU isn't something we control. This has been discussed in great detail on this list in the past. I encourage you to review the archives and threads of that discussion. Stephen signature.asc Description: Digital signature
Re: amd64 - x86_64
* Robert Millan ([EMAIL PROTECTED]) wrote: On Fri, Jul 23, 2004 at 08:58:48PM +0200, Kurt Roeckx wrote: DEB_HOST_ARCH=amd64 DEB_HOST_GNU_CPU=x86_64 This are the correct values. How do you determine when a value is correct? All I have seen so far are arbitrary marketing decisions. Funny, the tech ctte ruled on it, with quite a few reasons outlined in their ruling. You might read it sometime. I'm mildly amused that you feel their decision is an 'arbitrary marketing decision'. This is also what the official dpkg returns since a few days ago. After all the hassle with the dpkg maintainers and the technical comitte, I'd have never expected the amd64 porters to defend a naming scheme based on what official dpkg returns. The point is that it returns what it does now because of the technical committee ruling and the desire of the porters. DEB_HOST_GNU_CPU is the the GNU tools use. They use x86_64 on The GNU tools (i.e. config.sub) accept both, so it's not an issue. The kernel also uses x86_64, as I recall. Certainly this is the arrangement that works and is being used currently. I see no justification for changing it. Stephen signature.asc Description: Digital signature
Re: amd64 - x86_64
* Robert Millan ([EMAIL PROTECTED]) wrote: Now that the technical comitte has ruled in favour of 'amd64' for the debian archname (DEB_HOST_ARCH variable), I wonder what will happen with the other dpkg-architecture variables, which are actualy much more important than the architecture name dpkg uses internaly to identify debian ports. DEB_HOST_ARCH = amd64 DEB_HOST_GNU_CPU = x86_64 etc. Users and developers can understand it. It's hardly a 'dual naming', and if you're going to be concerned about it being one go look at all of the *other* 'dual naming's we have in Debian already. Stephen signature.asc Description: Digital signature
Re: gcc-defaults: Please make gcc-3.4 the default on amd64
* Andreas Jochens ([EMAIL PROTECTED]) wrote: Please make gcc-3.4 the default on amd64. It has much better support for the amd64 architecture and also much better performance on amd64 than gcc-3.3. Greetings, all. Just wanted to say that I support this move. I think it makes sense, esp. considering 3.4 will be in sid shortly. Even if we manage to somehow get into sid and through testing in time to release with sarge I don't believe this will be a problem for us. Provided the gcc-3.4 transisiton is done on all archs prior to multiarch I don't think that will even be a problem. If anyone has any objections to this move, please raise them now, and quickly, so we can get to a final decision soon. Stephen signature.asc Description: Digital signature
