@pmatilai What does #1028 have to do with this? Michael Schroeder isn't even in
there.
Anyway, aside from that, it _looks_ sane, I need to test it, though...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Oh, @ppisar, I guess you wrote that patch :D
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/#issuecomment-597801394___
[This project](https://metacpan.org/release/rpm-build-perl) aims to provide
replacements that hook into the compiler backend of Perl and could
theoretically give better answers. I had to apply a
I noticed that rpmspec -q --srpm foo.spec winds up getting evaluated
as the arch that youre running it on, which I expected, but also that
the arch winds up in the output, which I did not. I asked a pile of
other people and they were all surprised by this as well.
This patch changes rpmspec -q
For the package overall, it may be best to just use the Provides/Requires
mechanism with multiple things being generated, e.g.
Requires: cpu(arm)
Requires: cpu(neon)
Requires: cpu(thumb)
or
Requires: cpu(x86_64)
Requires: cpu(mmx)
Requires: cpu(sse)
Requires: cpu(sse2)
where cpu(*) features
I think I did okay in this PR avoiding many freak cases, though I definitely
see your point about the broader architecture handling.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> For example, while the arch marker generation seems pretty obvious in
> general, starting something new with hardcoding ARM stuff gives me the
> willies. I want ARM to stop being the freak case that always being worked
> around, and have the design flexible enough to cover it.
I'm not
This needs to be looked at together as a whole with any arch handling changes
we are about to do, so we don't end up doing something now that we'll bitterly
regret in six months time. So we need to build up the big picture first.
For example, while the arch marker generation seems pretty
@ppisar , that changes like this have potential for regressions is obvious even
to a perl-illiterate like myself. Let me rephrase that question: would *you*
merge this? If it's left up to me, I'll hit the merge button in a day or two if
only because I don't know any better :smile:
--
You are
Oh, another use case for some new architecture detection and handling library.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Meh. I am still not a big fan of this solution, but we can still change the
defaults later on. It indeed seems unlikely someone won't ship the compat
Provides anytime soon.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Try the configured backend first, and only if that fails try autodetection.
The former logic did not anticipate multiple backends handling same
files and gets mightily confused when both bdb and bdb-ro are enabled,
causing half the test-suite failing in make check.
Also emit a different message
That's a fair point, once you have a more fleshed out commit message for this,
then I'd be happy look over it for final review. At least code-wise, looks
good.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Being optional might be a matter of perspective: prior to rpm 4.13, file
classes and colors were not populated if external dependency generator was
used, which always was a smallish but non-ignorable set of packages.
We could certainly do this in stages as well, ie first add MIME and then later
Incidentally, that's why I'm always populating biarch Provides. We're going to
be stuck with them for a _long_ time due to RHEL and SLE and proprietary
software.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo approved this pull request.
In general, I think the approach looks good, and the added test seems to agree
with me, so if you feel this is the way to go, then I'm okay with it.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
> Can you try explaining why this makes you uneasy? (I know well enough it's
> not always easy to say)
I think the thing that makes me uneasy is that we're simultaneously no longer
populating `RPM_FILECLASS`. It's pretty rare that we do something like that.
I'm semi-concerned about the quality
> > I don't seem to see an obvious source for mime data for rpm to populate
> > MIME types for files?
>
> Hmm? That source was added in commit
> [e49111d](https://github.com/rpm-software-management/rpm/commit/e49111d822dc1c0715f5a85ed61523b4d020ae33),
> this just builds on top of that. That,
> I don't seem to see an obvious source for mime data for rpm to populate MIME
> types for files?
Hmm? That source was added in commit e49111d822dc1c0715f5a85ed61523b4d020ae33,
this just builds on top of that.
--
You are receiving this because you are subscribed to this thread.
Reply to this
Can you try explaining why this makes you uneasy? (I know well enough it's not
always easy to say)
Thing is, aside from the class info being unreliable as hell, the file class
data has always been optional and not all packages have it, so nothing at all
can *rely* on it.
--
You are receiving
@pmatilai Maybe I'm blind and I missed something, but I don't seem to see an
obvious source for mime data for rpm to populate MIME types for files?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
pmatilai commented on this pull request.
> @@ -396,13 +397,21 @@ rpm_loff_t rpmfilesFSize(rpmfiles fi, int ix);
rpm_color_t rpmfilesFColor(rpmfiles fi, int ix);
/** \ingroup rpmfiles
- * Return file class from file info set.
+ * return file class from file info set.
By mistake, rather
@ffesti If someone is trying to build a cross-distro package, accounting for
legacy from a newer-ish system (think Google Chrome or Bluejeans/Zoom Linux
RPMs being built on a specific host and shipped for everybody), being able to
flip behaviors makes sense.
--
You are receiving this because
I'm still somewhat uneasy about this change, but at least we're not repurposing
an existing field anymore...
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Conan-Kudo requested changes on this pull request.
> @@ -396,13 +397,21 @@ rpm_loff_t rpmfilesFSize(rpmfiles fi, int ix);
rpm_color_t rpmfilesFColor(rpmfiles fi, int ix);
/** \ingroup rpmfiles
- * Return file class from file info set.
+ * return file class from file info set.
Why did you
"Plan 1" now implemented for comparison in #1114.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1099#issuecomment-597580325___
This is an alternative to #1099, making a clear distinction between the old
class info and new MIME stuff.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Add new tags, rpmfiles APIs and other infra to support storing and
querying file MIME types. Store MIME type for all files, stop adding
rather arbitrarily filtered file class data as this is bloated and
relatively useless data, remove related cruft.
Fixes: #1096
You can view, comment on, or merge
While looking at this, I rediscovered (oh the things you write and forget)
makeClass() in lib/tagexts.c.
Which makes me think the answer is probably 1), ie leave the *CLASS* tags alone
but stop populating the header with them, and add new MIME tags instead.
--
You are receiving this because
29 matches
Mail list logo
