RPMTAG_ARCH gonna die! die! die! (step 6)

The attached patch changes rpm default behavior to not read
rpmrc  
files unless
a --rcfile option is explicitly specified.

The patch also updates various default values to current
practice.

I'm inclined to continue ripping out rpmrc files entirely
before  
releasing
rpm-4.4.7.

However, I will listen to reason if various distros cannot
move so  
quickly.

So if you have reservations about the changes,  or prefer
the  
existing behavior
in rpm for some reason, please speak up now.

If I've heard no opinions by next week, I shall rip out
rpmrc  
processing entirely
before releasing rpm-4.4.7.

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

I'm been looking at all of the patches.  They all make a
lot of sense to me.

I only have two issues that I ask you keep in mind as you
keep
implementing these changes.

1) How do we protect idiot users from themselves.. From my
experience..
 PPC users attempting to install ia32 packages (without any
ability to
run the software.)

2) For embedded platforms often times there are small ABI
changes
depending on compile options.  (The biggest of which is soft
vs hard
float.)  Currently I am dealing with this by using ARCH..
(not that I
want to mind you!).

How will I be able to keep incompatible binaries from being
install
without the ARCH checks?  (I suspect I may be able to use
something like
CPU features.. but really what I want is ABI features.)

Thanks!
--Mark

Jeff Johnson wrote:
> The attached patch changes rpm default behavior to not
read rpmrc files
> unless
> a --rcfile option is explicitly specified.
> 
> The patch also updates various default values to
current practice.
> 
> I'm inclined to continue ripping out rpmrc files
entirely before releasing
> rpm-4.4.7.
> 
> However, I will listen to reason if various distros
cannot move so quickly.
> 
> So if you have reservations about the changes,  or
prefer the existing
> behavior
> in rpm for some reason, please speak up now.
> 
> If I've heard no opinions by next week, I shall rip
out rpmrc processing
> entirely
> before releasing rpm-4.4.7.
> 
> 73 de Jeff
> 
> 
>
------------------------------------------------------------
------------
> 
> _______________________________________________
> Rpm-devel mailing list
> Rpm-devellists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Aug 7, 2006, at 5:50 PM, Mark Hatle wrote:

> I'm been looking at all of the patches.  They all make
a lot of  
> sense to me.
>
> I only have two issues that I ask you keep in mind as
you keep
> implementing these changes.
>
> 1) How do we protect idiot users from themselves.. From
my  
> experience..
>  PPC users attempting to install ia32 packages (without
any ability to
> run the software.)
>

Filtering of platforms that cannot be handled will be
accomplished by
applying regexes from lines 2-N in /etc/rpm/platform.

The patterns are already being read, I've just not gotten
around to
adding in the two places needed: 1) BuildArch: handling 2)  
rpmtsAddInstallElement().

> 2) For embedded platforms often times there are small
ABI changes
> depending on compile options.  (The biggest of which is
soft vs hard
> float.)  Currently I am dealing with this by using
ARCH.. (not that I
> want to mind you!).
>

Hmmm ... If the hard/soft presence is explicitly in
/proc/cpuinfo, then
     Requires: cpuinfo(field) = value
should probe the dependency at run-time quite nicely.

If the hard/soft ABI marker is somplace deeper in the /proc
and /sys  
zoo, I'll
be happy to add a dependency name space like cpuinfo(...) to
drill the
test into rpm dependencies.

> How will I be able to keep incompatible binaries from
being install
> without the ARCH checks?  (I suspect I may be able to
use something  
> like
> CPU features.. but really what I want is ABI features.)
>

With emulators, there ain't no such thing as
"incompatible" anymore,  
only
better tracking of nitpicky, finer grained, dependencies.

See the Subject: line, RPMTAG_ARCH is entirely the wrong
name space
for detecting "incompatibilities", finer
grained, run time probes, like
     Requires: cpuinfo(field) = value
instead.

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

Jeff Johnson wrote:
>> 2) For embedded platforms often times there are
small ABI changes
>> depending on compile options.  (The biggest of
which is soft vs hard
>> float.)  Currently I am dealing with this by using
ARCH.. (not that I
>> want to mind you!).
>>
> 
> Hmmm ... If the hard/soft presence is explicitly in
/proc/cpuinfo, then
>     Requires: cpuinfo(field) = value
> should probe the dependency at run-time quite nicely.

Unfortunately /proc/cpuinfo can't be relied on for FPU
information
because most architectures support FP emulation in the
kernel.. (and
there are occasionally reasons to run hard float on a CPU
w/o an FPU.)

> If the hard/soft ABI marker is somplace deeper in the
/proc and /sys
> zoo, I'll
> be happy to add a dependency name space like
cpuinfo(...) to drill the
> test into rpm dependencies.

There is nothing that I am aware of in the system to tell if
it's hard
or soft float.  It's only the way the applications are
compiled.  I am
asking someone more knowledgeable about ELF if there is any
type of a
marker in the elf that will tell if something is soft or
hard float.

(he already got back to me.. basically it's available on a
few
architectures.. but it's rarely simple to gleam from a
binary.)

>> How will I be able to keep incompatible binaries
from being install
>> without the ARCH checks?  (I suspect I may be able
to use something like
>> CPU features.. but really what I want is ABI
features.)
>>
> 
> With emulators, there ain't no such thing as
"incompatible" anymore, only
> better tracking of nitpicky, finer grained,
dependencies.

True.. I just don't want to blow away the (native) glibc w/
a version
that we may need for emulation.    But this
should be a known issue
already.

> See the Subject: line, RPMTAG_ARCH is entirely the
wrong name space
> for detecting "incompatibilities", finer
grained, run time probes, like
>     Requires: cpuinfo(field) = value
> instead.

Ya, I suspect that I may have to add something like
"ABI(field) = value"
because of this.  It may just be something I have to set
during
compilation.  (I also have the added complexity of cross
compilation..
but thats pretty much just macro specific...)

That does lead me to one question.  When cross compiling is
there a
simple way to pass a "this rpm requires this
feature", instead of adding
a manual Requires: to the package..

I think a macro of some kind that adds a build time
dependency may be
useful for the cross-compile special case.

--Mark

> 73 de Jeff
> _______________________________________________
> Rpm-devel mailing list
> Rpm-devellists.dulug.duke.edu
> https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Aug 7, 2006, at 7:00 PM, Mark Hatle wrote:

> Jeff Johnson wrote:
>>> 2) For embedded platforms often times there are
small ABI changes
>>> depending on compile options.  (The biggest of
which is soft vs hard
>>> float.)  Currently I am dealing with this by
using ARCH.. (not  
>>> that I
>>> want to mind you!).
>>>
>>
>> Hmmm ... If the hard/soft presence is explicitly in
/proc/cpuinfo,  
>> then
>>     Requires: cpuinfo(field) = value
>> should probe the dependency at run-time quite
nicely.
>
> Unfortunately /proc/cpuinfo can't be relied on for FPU
information
> because most architectures support FP emulation in the
kernel.. (and
> there are occasionally reasons to run hard float on a
CPU w/o an FPU.)
>

Lack of a FPU is certainly detectable from /proc/cpuinfo on
the  
platforms I've seen.

>> If the hard/soft ABI marker is somplace deeper in
the /proc and /sys
>> zoo, I'll
>> be happy to add a dependency name space like
cpuinfo(...) to drill  
>> the
>> test into rpm dependencies.
>
> There is nothing that I am aware of in the system to
tell if it's hard
> or soft float.  It's only the way the applications are
compiled.  I am
> asking someone more knowledgeable about ELF if there is
any type of a
> marker in the elf that will tell if something is soft
or hard float.
>
> (he already got back to me.. basically it's available
on a few
> architectures.. but it's rarely simple to gleam from a
binary.)
>

Well, DT_NEEDED for -lm is one (perhaps crude) way of
telling if float
is/was needed.

And writing a converter to do objdump -D, grepping out every
occurence
of floating point assembly, is another cude (but reliable
 way
to  
automate
detection and generating a dependency.

See the archives on this list from April (iirc) for some
ways to  
precisely detect
exactly what compiler flags were used for every object file
(a  
wrapper for gas
would be needed to parse the gcc flag spewage from the .s
files, and  
then
further processing to possibly detect need for FPU).

>>> How will I be able to keep incompatible
binaries from being install
>>> without the ARCH checks?  (I suspect I may be
able to use  
>>> something like
>>> CPU features.. but really what I want is ABI
features.)
>>>
>>
>> With emulators, there ain't no such thing as
"incompatible"  
>> anymore, only
>> better tracking of nitpicky, finer grained,
dependencies.
>
> True.. I just don't want to blow away the (native)
glibc w/ a version
> that we may need for emulation.    But this
should be a known issue
> already.
>

Pain is the best teacher, you've learned not to do
     cd /
     rm -rf foo *
the hard way, I'm sure that blowing away the host's glibc
is a better  
lesson
than whatever I could concoct in rpm 

>> See the Subject: line, RPMTAG_ARCH is entirely the
wrong name space
>> for detecting "incompatibilities",
finer grained, run time probes,  
>> like
>>     Requires: cpuinfo(field) = value
>> instead.
>
> Ya, I suspect that I may have to add something like
"ABI(field) =  
> value"
> because of this.  It may just be something I have to
set during
> compilation.  (I also have the added complexity of
cross compilation..
> but thats pretty much just macro specific...)
>
> That does lead me to one question.  When cross
compiling is there a
> simple way to pass a "this rpm requires this
feature", instead of  
> adding
> a manual Requires: to the package..
>
> I think a macro of some kind that adds a build time
dependency may be
> useful for the cross-compile special case.
>

Lots of ways to design a dependency chain. I'm not sure
that "needs  
cross compilation"
is a well designed dependency though, although somehow
indicating  
cross-compiler
was used is almost certainly wise for tracking purposes.

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

Jeff Johnson wrote:
>> That does lead me to one question.  When cross
compiling is there a
>> simple way to pass a "this rpm requires this
feature", instead of adding
>> a manual Requires: to the package..
>>
>> I think a macro of some kind that adds a build time
dependency may be
>> useful for the cross-compile special case.
>>
> 
> Lots of ways to design a dependency chain. I'm not
sure that "needs
> cross compilation"
> is a well designed dependency though, although somehow
indicating
> cross-compiler
> was used is almost certainly wise for tracking
purposes.

I didn't mean "requires cross compilation"..
but a way to specify what
cpuinfo would be available if this was compiled
self-hosted.. (and/or
other dynamic dependency items that would have been
available with a
self-hosted build.)

--Mark
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

---snip---

Add a "will most likely break X" list to those
mails, you'll make a lot of 
people happier 


-- 
Judge others by their intentions and yourself by your
results.
                                                            
    Guy Kawasaki
Education is an admirable thing, but it is well to remember
from
time to time that nothing that is worth knowing can be
taught.
                                                            
     Oscar Wilde
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Aug 9, 2006, at 6:11 PM, Mariusz Mazur wrote:

> ---snip---
>
> Add a "will most likely break X" list to
those mails, you'll make a  
> lot of
> people happier 
>

ATM, adding an explicit --rcfile, even with --target, breaks
nothing  
I have yet detected.

Having
	include: /usr/include/rpm
in existing per-vendor config is likely broken, but then its
always  
been broken
(as reported in a recent bugzilla). There's a number of
ways to  
restore the
ability to have
	include: /usr/lib/rpm
that I know about.

Oh yeah, translating, say, "i686" to
"i386" is broken w/o --rcfile.
Presumably any intelligent developer can arrange for
	rpmbuild --target i386-linux
where needed. Or alternatively, edit /etc/rpm/platform and
put "i386"  
instead of "i686".

Do you really *need* rpmbuild to do s/i686/i386/? If so, I
will  
arrange for that
to happen.

And nothing else is currently different than before AFAIK.

So the issue is not "will most likely break X",
but rather "Do  
distros need time
to convert, or can I rip --rcfile next week?" is the
question.

73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Aug 9, 2006, at 6:11 PM, Mariusz Mazur wrote:

> ---snip---
>
> Add a "will most likely break X" list to
those mails, you'll make a  
> lot of
> people happier 
>

Add to the list
	BuildArch: noarch bing bang boom
in spec file will not silently the non-existent arches
"bing bang boom".
There's certainly no usage like that in any FC packages,
grep  
BuildArch: from your specs.

And the archOkay()/osOkay() checks have been currently
ripped out of  
rpmtsRun()
(where they never should have been added in the first
place.)

I fully intend to re-add those checks in
rpmtsAddInstallElement(),  
the earliest
possible point at which policy decisions as in archOk() and
osOkay()  
can be made.

The archnum and osnum are no 0 in the rpmlead. <shrug>

Grep DIEDIEDIE in the sources for explictly marked changed
behavior,  
there's only
4 or 5 places iirc.

73 de Jeff

_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel

On Wed, 2006-08-09 at 18:29 -0400, Jeff Johnson wrote:
> On Aug 9, 2006, at 6:11 PM, Mariusz Mazur wrote:
> 
> > ---snip---
> >
> > Add a "will most likely break X" list
to those mails, you'll make a  
> > lot of
> > people happier 
> >
> 
> ATM, adding an explicit --rcfile, even with --target,
breaks nothing  
> I have yet detected.

> Oh yeah, translating, say, "i686" to
"i386" is broken w/o --rcfile.
> Presumably any intelligent developer can arrange for
> 	rpmbuild --target i386-linux

This assumes everyone is calling rpmbuild manually -
obviously there are
buildsystems and such to consider.

> where needed. Or alternatively, edit /etc/rpm/platform
and put "i386"  
> instead of "i686".

Are you going to nuke the asm for arch detection too?

> Do you really *need* rpmbuild to do s/i686/i386/? If
so, I will  
> arrange for that
> to happen.

I think there is an actual need for that.

How about things like ExclusiveArch and ExcludeArch and
%ifarch in
specs.

I'm not convinced rushing it through in a week into a minor
revision
bump is enough time to be honest.  I'd rather see it in
HEAD or a 4.5.x
branch and not in 4.4.x, it seems a big enough change to
target a major
revision not just an incremental release.

Paul

_______________________________________________
Rpm-devel mailing list
Rpm-devellists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel