> `RPMTAG_BUILDTIME` is recorded from the machine that builds it.
Yes, I know what `RPMTAG_BUILDTIME` is and for what it has been made.
> In addition, I'm not sure it's sane for repositories to contain multiple
> packages of the same NEVRD with different build-times and consider them
> unique.
of possibility, especially since even yum can do it.
If I understand the point correctly, it is like I want to implement it in apt,
but some has doubts that this is a big security issue, and this is fair enough.
> @wladmis What is the value of considering the build-time? That would
> introd
> @wladmis So I've seen that this is more fleshed out in ALT Linux's rpm, do
> you plan on finishing up this PR for consideration?
Yes, I want to finish the PR, but I have some doubts I wrote below.
> JFYI for everyone else, it looks like ALT has implemented `E:V-R:D`
&g
> I've submitted this:
> https://fedoraproject.org/wiki/Changes/Automatic_strict_inter-package_dependencies
> pkgconfig(graphene-1.0) is provided by graphene-devel (coming from the same
> subpackage), so it can be dropped entirely
This looks a bit ambiguous, it may be understood as you propose
> This has been implemented in ALT here:
> http://git.altlinux.org/gears/r/rpm-build.git?p=rpm-build.git;a=blob_plain;f=build/interdep.c;hb=HEAD.
> That code does different things and hard to read, but that is where we can
> steal some ideas.
In that part of code the following happens (A, B an
You can test this fix on [this
package](http://ftp.altlinux.org/pub/distributions/ALTLinux/2.2/Master/ALTLinux/RPMS/SysVinit-usermode-1.0-alt1.noarch.rpm),
for example.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https:
like pr#610, but for 4.13.x
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/611
-- Commit Summary --
* lib/packages.c: fix headerVerifyRegion() to handle old packages that use
HEADERIMAGE
-- File Changes --
M lib/pack
This fix is based on commit 21818c6c8f3d4fe7836326d27f38421c29c22db7,
which fix was lost in commit 85a5b004306fe8486424142cdc98575c25142776.
Related bugreport ALT#33710:
https://bugzilla.altlinux.org/show_bug.cgi?id=33710
You can view, comment on, or merge this pull request online at:
https://
@Conan-Kudo recently I take a brief look at OpenMandriva Lx3. It uses
`%name-%version-%release-%disttag%distepoch.%arch.rpm` for filename, each of
its rpm package provides `name =
%|epoch?{%{epoch}:}|%version-%release:%distepoch`, which is nice.
There is no `distepoch` in `rpm.org`, and in ALT
> However, from ALT's point of view and ALT's practice, conceptually, there is
> a kind of package dependency which can be satisfied only if another package's
> disttag is equal to the value specified in this dependency.
I think it is off topic. I want to tell about this later, but this requires
> I think that being able to put this value in the filename can be desired. And
> it's better to have the same format, so `/` is bad.
Even if `\` bas for filenames, we can use it for the format, and separate
`DistTag` with some other symbol lile `.` or `:` in the filename. It would be
ugly, I
> @wladmis What do you mean by "build matching"? I'm not sure I understand what
> you're saying here...
It may be more clear by example. As there are different builds of the same
NEVR, there can be situation that two (or more) different builds can be
simultaneous
Let's decide which the format `dbiFindByLabelArch()` should match.
--
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/issues/589#issuecomment-437612833__
> ignatenkobrain: I don't think it makes sense to allow the disttag in
> dependencies, aka EVR. It's for the "canonical" package name, i.e. NEVRA.
Definitely it does not make sense to allow `DistTag` in dependencies because
`DistTag` shows an alternative build: generally, there is no order. Mean
wladmis commented on this pull request.
> @@ -731,13 +731,14 @@ int rpmdbCountPackages(rpmdb db, const char * name)
}
/**
- * Attempt partial matches on name[-version[-release]][.arch] strings.
+ * Attempt partial matches on name[-version[-release]][/disttag][.arch]
strings.
@Conan-K
wladmis commented on this pull request.
> @@ -731,13 +731,14 @@ int rpmdbCountPackages(rpmdb db, const char * name)
}
/**
- * Attempt partial matches on name[-version[-release]][.arch] strings.
+ * Attempt partial matches on name[-version[-release]][/disttag][.arch]
strings.
I don
wladmis commented on this pull request.
> @@ -731,13 +731,14 @@ int rpmdbCountPackages(rpmdb db, const char * name)
}
/**
- * Attempt partial matches on name[-version[-release]][.arch] strings.
+ * Attempt partial matches on name[-version[-release]][/disttag][.arch]
strings.
I decided
Related to #589.
I'm not sure, but if it is OK, there can be a new feature to handle `DistTag`
(named `rpmlib(HandleDistTag)`, for example) that is required if there is
non-empty `DistTag` while package is building.
Something like:
+++ build/pack.c (in proper place):
/* if DistTag is n
Thank you! But only after this PR was merged I found that commit message was
not quite correct: I wrote that different builds differ *only* in DistTag, but
it is obvious it is not true: they could differ by some other header tags, such
as BuildTime, or could differ in files generated during buil
Ok, now it is DistTag.
--
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/590#issuecomment-435613935___
Rpm-maint mailing list
Rpm-m
wladmis commented on this pull request.
> @@ -102,6 +102,7 @@ Name: %{NAME}\n\
%|EPOCH?{Epoch : %{EPOCH}\n}|\
Version : %{VERSION}\n\
Release : %{RELEASE}\n\
+%|DISTTAG?{Disttag : %{DISTTAG}\n}|\
DistTag it is.
--
You are receiving this because you are subscri
replaced tab with spaces
--
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/590#issuecomment-435516427___
Rpm-maint mailing list
Rpm
woops, repushed...
--
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/590#issuecomment-435489018___
Rpm-maint mailing list
Rpm-maint
In ALT there can be different builds of the same NEVR which only
differ in disttag, so it is useful to print its value as part of
package information.
Signed-off-by: Vladimir D. Seleznev
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/
> * Is different disttag for same EVR -- alternatives or ordered number?
Alternatives.
> * I don't like either `.` or `-` because those are widely used everywhere
> so you basically need to change all software which are parsing EVR.
That's true. That is one of reason why I begin the dis
> I think probably the most sane format would be
> `name[-[epoch:]version-[release[.disttag]]][.arch]`.
Thanks for reply, but this format has same disadvantage as that I've proposed,
and unlike "dash" symbol a "dot" symbol is a valid symbol for release, so if it
will be separator for disttag i
There is in ALT we use `disttag` as one of build id of package builds (it
stores `repository_name.buildtask.subtask`), so we need that rpm can handle it.
In [this
message](http://lists.rpm.org/pipermail/rpm-maint/2018-October/008949.html) I
proposed a format like `name[-[epoch:]version-[release
One of main task to solve: what we should do with tags that were used
previously and do not used now, and tags that can be added in the future, but
are not present in rpm now.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
The previous discussion was
[here](http://lists.rpm.org/pipermail/rpm-maint/2018-April/007718.html).
Main thought:
- compute identity as a digest of filtered iterated pair of tags and its values
of immutable header region;
- change the awk script that generates the tag table to add a marker (lik
There was a suggestion to [calculate RPMTAG_IDENTITY as tag
extension](http://lists.rpm.org/pipermail/rpm-maint/2018-March/007688.html) and
do not the tag to actual rpm package during build time.
The main idea is to take message digest from package header tags filtered by
the blacklist containi
30 matches
Mail list logo
