[cooker-amd64] Re: Re: Re: using and compiling rpms not specifically put together for amd64

[Duncan]

Arie Folger posted <200401261756.43759.afolger@aishdas.org>, excerpted
below,  on Mon, 26 Jan 2004 17:56:43 +0100:

> So will --target x86_64 be safe to use in all cases, except for those that
> are beyond easy tweaking? (i.e., will that target be harmless to the first
> category?)

Well, I've learned to be wary of unqualified no-exception terms such as
"all", when applied as above, ESPECIALLY when "safe" is attacked, as in
"safe in ALL cases".  I'm just not comfortable with that level of
absoluteness in the statement.  See for example the L-whatever dead CD
issue of i586 9.2 full release.  That hit EVERYONE out of the blue,
including everyone on cooker.  There was NO HINT of such a problem, or
Mdk wouldn't have released it.

That said, in THEORY, --target x86_64 should be safe (harmless) for use in
the general case, yes.  I was digging around in some more SRPMs, 2.6
kernel SRPMs in this case, and this is straight out of the spec file:

# Aliases for amd64 builds (better make source links?)
%define target_cpu      %(echo %{_target_cpu} | sed -e "s/amd64/x86_64/")
%define target_arch     %(echo %{_arch} | sed -e "s/amd64/x86_64/")

Thus, as you can see, all the spec file does with amd64 is substitute in
x86_64 internally, anyway.  That's the standard approach, it would seem,
from what I recall from looking at previous spec files, so either manually
specifying the --target x86_64 switch with each rebuild, or manually
changing your installed rpm macros to do likewise and specify that
automatically rather than the amd64 they now specify, should work, at
least for current packages.

Whether that approach will remain in the Mdk spec files forever, however,
I'm not sure we know, yet.  It's possible they will eventually make amd64
default, and x86_64 an alias to it, and then do away with x86_64 all
together.

The two are not in theory absolutely equivalent in meaning, either, and in
fact the kernel spec files don't treat them exactly the same, by my read
(tho I don't yet understand the specifics of rpm macros, so my read could
be wrong if it looks for such aliases first, applying them globally, even
to stuff above them in the physical config file).

Technically, x86_64 is the generic term for the general architecture,
while amd64 would be AMD's specific implementation thereof.  At this
point, AMD's implementation is the ONLY implementation, but that won't
necessarily be the case moving forward.  Intel has been widely predicted
as eventually giving up on its ia64 architecture, and doing its own
implementation of x86_64.  AMD and Intel DO have cross-licenses that
should allow Intel to do so, just as AMD was able to institute Intel's
SIMD instructions.  (Of course, x-licensing of patents, etc. doesn't cover
trade-mark, etc, so AMD continues to call its full implementation
3D-NOW-Pro or some such, rather than using the Intel trademarked brand
name, and internal implementation may be different meaning possible
small differences in efficiency, but that's not within the scope of the
current discussion.)  Of course, when Intel does so, they'll likely put
their own twist on it, and then we will see a difference emerge between
the generic term and the branded term.  Whether it will be different
enough to break compatibility with current x86_64 target labels, and thus
mandate coming up with a different generic term to avoid breakage, remains
to be seen, but...  In addition, if AMD64 continues to be successful,
there will inevitably be further implementations of the architecture, with
the Vias and the SiSs of the world doing their own version, likely missing
key parts of the branded implementation, and causing headaches for
software platform implementors, much as there were initial problems with
the generic versions of the various generations of ix86.  Thus, the two
terms can be EXPECTED to diverge a bit if the general platform is as
successful as AMD hopes and it would appear many of us here are predicting
and voting for with our own behavior.

In specific current terms, as I mentioned, at least some current specs
define the alias below the first use of one or the other specific terms. 
In the case of the kernel specs I'm looking at. the above alias definition
is below the following conditionals:

%ifarch alpha x86_64 ia64
%define build_enterprise 0
%else
%define build_enterprise 1
%endif

%ifarch %{ix86} x86_64
%define build_BOOT 1
%else
%define build_BOOT 0
%endif

%ifarch %{ix86} x86_64
%define build_secure 1
%else
%define build_secure 0
%endif

Thus (again, unless rpm macro behavior is such that aliases are evaluated
first, but I'm guessing it's all just evaluated in order, since I don't
know at this point..), those conditionals will work one way with x86_64
defined, the opposite way with amd64 defined.  I expect this particular
example is a bug in the spec file, but that may not ALWAYS be the case,
for the generic vs. branded implementation reasons examined above.

Stephan?  What's your take?  The above is a bug, right?  Or am I off in my
interpretation, somewhere?

> BTW, now that I understand what you meant by trouble (trying to use
> contribs that weren't on the isos) I, too, share in that trouble, though
> it is part of the fun of being on the bleeding edge. (eh, I don't use
> cooker, so I shouldn't exagerate).

Well, unless you are working off the full release already, you are already
using Cooker to some degree, altho the RCs are snapshots of Cooker that
at least aren't supposed to do anything TO drastic, like erasing or
corrupting disks! <g>  Still, it's cooker enough, and there are few enough
running full cooker that it's a very good idea to either not run it on
anything with data you couldn't afford to lose, or at minimum, have good
backups.

.. For that matter, even full releases.. look at the LG or whatever it was
CDROM problem with the full 9.2 release.  That hit *EVERYBODY* by
surprise, *NO* hint that it was coming.  I know as I was doing full blown
i586 cooker for the entire cycle, and that was a post RC stage "minor"
tweak that wasn't supposed to have ANY weird consequences.    Still, it
didn't destroy data on the hard drive, but as out of the blue as that was,
it COULD have been a bug that did.

Anyway.. RCs are already a big step from releases only.  From there,
especially with something as new as AMD64 support, it's not a big step to
full cooker, because often the full cooker packages are simply more
functional updates off of the RCs, or initially available packages, not
available at RC snapshot time, and that wouldn't rebuild directly from the
RC snapshot period SRPMs.

Thus, you may not be running full blown regularly updated Cooker, but you
can't be running release yet, so you are running cooker of SOME sort, like
it or not.

[Duncan wrote..]
>> (That's one reason I'd prefer to have some sort of "electronic edition"
>> I could buy.. club doesn't provide anything of real value to me, and in
> 
> ... without needing the proprietary software. Then
> again, had I had an NVIDIA graphic card, I'd like those proprietary
> drivers.

I suppose that might be the case for the non-technically inclined that we
all hope are switching to Linux from proprietary-ware at this point (at
least for the practical reason of the most dominant of proprietary-ware
being MSWormOS, and their security woes affect us all to the extent of
the denial of service and inflated costs of net access due to the traffic
generated by the exploits of that insecurity..).

However, I DID run an NVIDIA card until recently, having to run their
proprietary-ware drivers because the libre ones didn't do multiple
displays, single card (unlike the ATI, which I switched to, because the
libre drivers for it DO support the second display on the same card).  I
did without the club drivers.  NVidia provides a workable, if hassling,
solution on its site, which non-tech people should find usable.  It was
more hassle here, because as a tech person, I'm frequently changing my
kernel, and having to constantly recompile the nvidia driver was a hassle.
Still, that hassle eventually caused me to switch cards, vowing NEVER to
go NVidia again until they correct this issue, which is the desired
reaction from a libre perspective.  Again, I DO NOT WANT to support
proprietary-ware with my $$, PERIOD!  Doing so only makes the folks using
it more comfortable, and the change less necessary, therefore harming the
cause I am attempting to support.  I understand why Mdk does it, yes, and
won't argue against them doing so at this point.  I just want to ensure
that none of MY $$ go to support that, even if it means not supporting Mdk
because of it -- there ARE other distributions out there, after all, but
there's nothing to replace the opportunity libre software affords to break
out of the tyranny of closed source.

(Ahhmm.. excuse my political rant, but..  <g>)

> Now, I still have one more question: I followed the links you sent me, but
> saw no amd64 plf rpms. Does that mean that I should download the srpms and
> build them, assuming that they are listed as function/compiling packages,

This one should really be addressed on the PLF list, but briefly.. I'm
not running PLF right now because my use of it is limited anyway, and I
haven't gotten around to doing the work locally to automate the process.  
Thus, I can't answer in detail from personal experience right now anyway. 
That said, discussion on the plf list, which I am still following (from
gmane's list2news gateway, thus via my news reader, as with all the Mdk
lists I follow), now DOES include discussion of amd64.  Specifically,
there's a thread over there in which both Stephan and I am participating,
where Stephan points out that PLF not only in fact DOES have amd64
binaries available, but that the PLF hdlists are the first to go
"unified", that is, have both AMD64 and i586 packages in the same unified
hdlist.  There are a few problems with that as he mentions, but it's his
opinion and from my limited experience I concur, that PLF is a good place
to try to work out the problems, and hammer (non-deliberate but
recognized play on words, there <g>) out the necessary policy and possible
urpmi bugs/patches required to get it working right (or eventually decide
it's not worth the hassle, to keep separate lists, as the main Cooker and
updates lists are, currently).

IOW, there ARE amd64 plf rpms available on at least some plf mirrors, and
there is even an urpmi compatible hdlist for them, unlike contribs, at
this point, but I don't have a specific URL to give you because I haven't
done the necessary reconfiguring here to run it, and even if I did, the
PLF list would be more appropriate for that discussion anyway.

Therefore, in short, go look at the PLF list for details (again, archive
on gmane.org) on that, but yes, amd64 binary plf packages ARE publicly
available, subject of course to their already being ported over, with
current status listed on Stephan's site as originally mentioned.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin