According to [1], using a dist tag is mandatory. However there are quite a few packages [2] where a dist tag is missing. I am curious if those are bugs and should be filed. Or are there any exceptions that I am missing?
The reason why I am asking is that we'd like to know if Taskotron can count on NVR's to have a dist tag in them.
Thanks! Martin
[1] https://fedoraproject.org/wiki/Packaging:DistTag [2] $ repoquery -qa --disablerepo=* --enablerepo=fedora --enablerepo=fedora-updates | sort | grep -v -F '.fc' bbkeys-0:0.9.0-20.x86_64 bouml-doc-0:4.3.2-9.noarch compat-libgfortran-41-0:4.1.2-45.i686 compat-libgfortran-41-0:4.1.2-45.x86_64 compat-libstdc++-296-0:2.96-146.1.i686 compat-libstdc++-33-0:3.2.3-68.12.i686 compat-libstdc++-33-0:3.2.3-68.12.x86_64 csmash-0:0.6.6-29.x86_64 fedora-package-config-apt-0:16.00-6.noarch fedora-release-0:22-1.noarch fedora-release-cloud-0:22-1.noarch fedora-release-server-0:22-1.noarch fedora-release-workstation-0:22-1.noarch fedora-repos-0:22-1.noarch fedora-repos-rawhide-0:22-1.noarch generic-release-0:22-0.4.noarch generic-release-cloud-0:22-0.4.noarch generic-release-nonproduct-0:22-0.4.noarch generic-release-notes-0:22-0.4.noarch generic-release-server-0:22-0.4.noarch generic-release-workstation-0:22-0.4.noarch gkrellm-aclock-0:0.3.4-14.x86_64 gkrellm-moon-0:0.6-16.x86_64 gnome-screensaver-frogs-0:0.2-13.noarch gtweakui-0:0.4.0-16.x86_64 kcbench-0:0.3-12.1.noarch kcc-0:2.3-37.x86_64 lmarbles-0:1.0.7-19.x86_64 mj-0:1.14-1.x86_64 oflb-riordonfancy-fonts-0:4-10.noarch python-autopep8-0:0.9.2-1.noarch python-ogg-0:1.3-21.x86_64 python-ogg-devel-0:1.3-21.i686 python-ogg-devel-0:1.3-21.x86_64 python-vorbis-0:1.5-0.15.a.x86_64 reinteract-0:0.5.9-10.noarch sbd-0:1.2.1-1.x86_64 shim-0:0.8-8.x86_64 torcs-data-0:1.3.3-5.noarch torcs-data-cars-extra-0:1.3.3-5.noarch torcs-data-tracks-dirt-0:1.3.3-5.noarch torcs-data-tracks-oval-0:1.3.3-5.noarch torcs-data-tracks-road-0:1.3.3-5.noarch websec-0:1.9.0-16.1.noarch wvs-data-0:0.0.20020219-11.noarch xhtml1-dtds-0:1.0-20020801.11.noarch xml2dict-0:0-0.7.2008.6.1.noarch xmms-acme-0:0.4.3-18.x86_64 xmms-arts-0:0.7.1-16.x86_64 xmms-lirc-0:1.4-21.x86_64 xmms-skins-1:1.2.10-28.noarch xmms-speex-0:0.9.1-21.x86_64
here's the meeting logs where disttag was made mandatory:
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12-04/fpc.2014-12-04-...
Looks like most of those packages could have it added but there are a few exceptions (the fedora-release-* packages were noted in that meeting).
-Toshio
On Tue, Jun 16, 2015 at 7:44 AM, Martin Krizek mkrizek@redhat.com wrote:
According to [1], using a dist tag is mandatory. However there are quite a few packages [2] where a dist tag is missing. I am curious if those are bugs and should be filed. Or are there any exceptions that I am missing?
The reason why I am asking is that we'd like to know if Taskotron can count on NVR's to have a dist tag in them.
Thanks! Martin
[1] https://fedoraproject.org/wiki/Packaging:DistTag [2] $ repoquery -qa --disablerepo=* --enablerepo=fedora --enablerepo=fedora-updates | sort | grep -v -F '.fc' bbkeys-0:0.9.0-20.x86_64 bouml-doc-0:4.3.2-9.noarch compat-libgfortran-41-0:4.1.2-45.i686 compat-libgfortran-41-0:4.1.2-45.x86_64 compat-libstdc++-296-0:2.96-146.1.i686 compat-libstdc++-33-0:3.2.3-68.12.i686 compat-libstdc++-33-0:3.2.3-68.12.x86_64 csmash-0:0.6.6-29.x86_64 fedora-package-config-apt-0:16.00-6.noarch fedora-release-0:22-1.noarch fedora-release-cloud-0:22-1.noarch fedora-release-server-0:22-1.noarch fedora-release-workstation-0:22-1.noarch fedora-repos-0:22-1.noarch fedora-repos-rawhide-0:22-1.noarch generic-release-0:22-0.4.noarch generic-release-cloud-0:22-0.4.noarch generic-release-nonproduct-0:22-0.4.noarch generic-release-notes-0:22-0.4.noarch generic-release-server-0:22-0.4.noarch generic-release-workstation-0:22-0.4.noarch gkrellm-aclock-0:0.3.4-14.x86_64 gkrellm-moon-0:0.6-16.x86_64 gnome-screensaver-frogs-0:0.2-13.noarch gtweakui-0:0.4.0-16.x86_64 kcbench-0:0.3-12.1.noarch kcc-0:2.3-37.x86_64 lmarbles-0:1.0.7-19.x86_64 mj-0:1.14-1.x86_64 oflb-riordonfancy-fonts-0:4-10.noarch python-autopep8-0:0.9.2-1.noarch python-ogg-0:1.3-21.x86_64 python-ogg-devel-0:1.3-21.i686 python-ogg-devel-0:1.3-21.x86_64 python-vorbis-0:1.5-0.15.a.x86_64 reinteract-0:0.5.9-10.noarch sbd-0:1.2.1-1.x86_64 shim-0:0.8-8.x86_64 torcs-data-0:1.3.3-5.noarch torcs-data-cars-extra-0:1.3.3-5.noarch torcs-data-tracks-dirt-0:1.3.3-5.noarch torcs-data-tracks-oval-0:1.3.3-5.noarch torcs-data-tracks-road-0:1.3.3-5.noarch websec-0:1.9.0-16.1.noarch wvs-data-0:0.0.20020219-11.noarch xhtml1-dtds-0:1.0-20020801.11.noarch xml2dict-0:0-0.7.2008.6.1.noarch xmms-acme-0:0.4.3-18.x86_64 xmms-arts-0:0.7.1-16.x86_64 xmms-lirc-0:1.4-21.x86_64 xmms-skins-1:1.2.10-28.noarch xmms-speex-0:0.9.1-21.x86_64 -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
here's the meeting logs where disttag was made mandatory:
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12-04/fpc.2014-12-04-...
Looks like most of those packages could have it added but there are a few exceptions (the fedora-release-* packages were noted in that meeting).
-Toshio
Thanks for the link. I'm not sure I understood the reason for having an exception for fedora-{release,repos}*. The log says:
17:41:58 <tibbs|w> There's no reason for them to do so, since their version is tied to the distro version.
Which is true, but why is that a reason to grant them an exception? Would it cause any problems it they contained a distro tag as well?
To clarify what we're trying to do in Taskotron: We work with NVRs quite a lot. Sometimes we need to know "which Fedora/EPEL version was this NVR built for?". We figured we could parse the dist tag, which is very efficient, but its presence needs to be guaranteed (if we don't want to maintain a list of hardcoded exceptions and use some different logic for those).
The only other approach we came up with is to query Koji for each NVR, retrieve the build info, and derive this information from the build target. The downside is that it involves a lot of requests to Koji. We want to avoid stressing the Fedora infrastructure unnecessarily, if we can figure out this information in some other (offline) way. This would also make our tests run longer and crash more often (every network request is a potential point of failure).
So, our question is whether we can rely on all packages having a dist tag (we will report bugs against those which don't). If we can't, we'll need to implement the less efficient way (at least for those missing the dist tag).
Thanks, Kamil
On Wed, 2015-06-17 at 03:48 -0400, Kamil Paral wrote:
here's the meeting logs where disttag was made mandatory:
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12 -04/fpc.2014-12-04-17.02.log.html
Looks like most of those packages could have it added but there are a few exceptions (the fedora-release-* packages were noted in that meeting).
-Toshio
Thanks for the link. I'm not sure I understood the reason for having an exception for fedora-{release,repos}*. The log says:
17:41:58 <tibbs|w> There's no reason for them to do so, since their version is tied to the distro version.
Which is true, but why is that a reason to grant them an exception? Would it cause any problems it they contained a distro tag as well?
Yes, because this is the package that provides the definition of the distro tag. It couldn't install itself.
On 06/17/2015 02:48 PM, Stephen Gallagher wrote:
On Wed, 2015-06-17 at 03:48 -0400, Kamil Paral wrote:
here's the meeting logs where disttag was made mandatory:
http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12 -04/fpc.2014-12-04-17.02.log.html
Looks like most of those packages could have it added but there are a few exceptions (the fedora-release-* packages were noted in that meeting).
-Toshio
Thanks for the link. I'm not sure I understood the reason for having an exception for fedora-{release,repos}*. The log says:
17:41:58 <tibbs|w> There's no reason for them to do so, since their version is tied to the distro version.
Which is true, but why is that a reason to grant them an exception? Would it cause any problems it they contained a distro tag as well?
Yes, because this is the package that provides the definition of the distro tag. It couldn't install itself.
Can't this be hard-coded into the package itself?
Ralf
Thanks for the link. I'm not sure I understood the reason for having an exception for fedora-{release,repos}*. The log says:
17:41:58 <tibbs|w> There's no reason for them to do so, since their version is tied to the distro version.
Which is true, but why is that a reason to grant them an exception? Would it cause any problems it they contained a distro tag as well?
Yes, because this is the package that provides the definition of the distro tag. It couldn't install itself.
Can you please explain that a bit more? Do you mean that the %{dist} macro is not available before fedora-release is installed, and therefore we couldn't _build_ the package? Because I don't understand why the package should be not installable if it had .fcXX suffix.
In any case, if there was just a very small set of packages which didn't use dist tag, but the information could be deduced some other way (from the version field), I think that would still work for us in Taskotron, we would hardcode the exceptions.
On Thu, 2015-06-18 at 06:38 -0400, Kamil Paral wrote:
Thanks for the link. I'm not sure I understood the reason for having an exception for fedora-{release,repos}*. The log says:
17:41:58 <tibbs|w> There's no reason for them to do so, since their version is tied to the distro version.
Which is true, but why is that a reason to grant them an exception? Would it cause any problems it they contained a distro tag as well?
Yes, because this is the package that provides the definition of the distro tag. It couldn't install itself.
Can you please explain that a bit more? Do you mean that the %{dist} macro is not available before fedora-release is installed, and therefore we couldn't _build_ the package? Because I don't understand why the package should be not installable if it had .fcXX suffix.
Sorry, yes. I meant that the macro would not be available at build -time. But as Ralf pointed out, I suppose we could hard-code the value rather than use %{?dist}, which makes sense.
I'm not sure of any other specific rationale for not including the dist in the Release: field. CCing Dennis Gilmore to see if he knows the specifics.
In any case, if there was just a very small set of packages which didn't use dist tag, but the information could be deduced some other way (from the version field), I think that would still work for us in Taskotron, we would hardcode the exceptions.
Dne 17.6.2015 v 09:48 Kamil Paral napsal(a):
To clarify what we're trying to do in Taskotron: We work with NVRs quite a lot. Sometimes we need to know "which Fedora/EPEL version was this NVR built for?". We figured we could parse the dist tag, which is very efficient, but its presence needs to be guaranteed (if we don't want to maintain a list of hardcoded exceptions and use some different logic for those).
Can you identify the version of Fedora using GPG key, which was used to sign the package?
Dne 17.6.2015 v 09:48 Kamil Paral napsal(a):
To clarify what we're trying to do in Taskotron: We work with NVRs quite a lot. Sometimes we need to know "which Fedora/EPEL version was this NVR built for?". We figured we could parse the dist tag, which is very efficient, but its presence needs to be guaranteed (if we don't want to maintain a list of hardcoded exceptions and use some different logic for those).
Can you identify the version of Fedora using GPG key, which was used to sign the package?
That's an interesting thought. But often we have just the NVR _string_, not the file itself. So this would require a network call anyway (downloading the RPM headers).
On Wed, Jun 17, 2015 at 03:48:10AM -0400, Kamil Paral wrote:
To clarify what we're trying to do in Taskotron: We work with NVRs quite a lot. Sometimes we need to know "which Fedora/EPEL version was this NVR built for?". We figured we could parse the dist tag, which is very efficient, but its presence needs to be guaranteed (if we don't want to maintain a list of hardcoded exceptions and use some different logic for those).
Sorry if this is a silly question, but for your use case, does it matter than the disttag says what it was built against, not what release it was shipped with? Because the dist tag only tells you the former, since we don't always rebuild everything.
On Wed, Jun 17, 2015 at 03:48:10AM -0400, Kamil Paral wrote:
To clarify what we're trying to do in Taskotron: We work with NVRs quite a lot. Sometimes we need to know "which Fedora/EPEL version was this NVR built for?". We figured we could parse the dist tag, which is very efficient, but its presence needs to be guaranteed (if we don't want to maintain a list of hardcoded exceptions and use some different logic for those).
Sorry if this is a silly question, but for your use case, does it matter than the disttag says what it was built against, not what release it was shipped with? Because the dist tag only tells you the former, since we don't always rebuild everything.
That is a good question, and it seems we will sometimes need to know the first thing (build target) and sometimes the other thing (ship target). For the latter, we will need to query Koji, there seems to be no way around that. For the former, we would like to avoid the query if possible.
The existing use case for using the build target is that packages will be able to define rule whitelists for certain checks (rpmlint, abipkgdiff) and store them in distgit. In order to download the correct whitelist, we need to know which distgit branch to check out. And that corresponds to the build target of the package (you don't even need to ship the package in fxx-updates(-testing), we want to check it right after it is built in Koji).
On 06/22/2015 12:08 PM, Kamil Paral wrote:
The existing use case for using the build target is that packages will be able to define rule whitelists for certain checks (rpmlint, abipkgdiff) and store them in distgit. In order to download the correct whitelist, we need to know which distgit branch to check out. And that corresponds to the build target of the package (you don't even need to ship the package in fxx-updates(-testing), we want to check it right after it is built in Koji).
Getting the whitelist from git seems difficult and error prone. Maybe it would be simpler to put it in the SRPM instead? That way, you would only have to unpack the matching SRPM and wouldn't have to access the git repo at all.
Adding the whitelist file as a SourceXX would make sure it's included in the SRPM.
On Mon, Jun 22, 2015 at 12:24:18PM +0200, Kalev Lember wrote:
Getting the whitelist from git seems difficult and error prone. Maybe it would be simpler to put it in the SRPM instead? That way, you would only have to unpack the matching SRPM and wouldn't have to access the git repo at all. Adding the whitelist file as a SourceXX would make sure it's included in the SRPM.
I assume that it's desirable to decouple test information — particularly this kind of thing like how and which tests — from the actual package. That way, you don't need to rebuild the package to turn on or off a particular test.
Getting the whitelist from git seems difficult and error prone. Maybe it would be simpler to put it in the SRPM instead? That way, you would only have to unpack the matching SRPM and wouldn't have to access the git repo at all.
Adding the whitelist file as a SourceXX would make sure it's included in the SRPM.
Thanks, Kalev, that is a very good idea. It has some pros and cons, as everything. We'll definitely think about this approach.
Regardless of what we do with whitelists, we'll still have some use cases where relying on the dist tag could improve our life, though :) Here's the most recent example: https://phab.qadevel.cloud.fedoraproject.org/T491
On 06/22/2015 12:08 PM, Kamil Paral wrote:
The existing use case for using the build target is that packages will be able to define rule whitelists for certain checks (rpmlint, abipkgdiff)
Also see how openSUSE does it:
https://en.opensuse.org/openSUSE:Packaging_checks#Suppressing_False_Positive...
On Mon, Jun 22, 2015 at 06:08:51AM -0400, Kamil Paral wrote:
The existing use case for using the build target is that packages will be able to define rule whitelists for certain checks (rpmlint, abipkgdiff) and store them in distgit. In order to download the correct whitelist, we need to know which distgit branch to check out.
I've been excited for a while¹ about letting packagers (along with other test contributors) add tests to a git tree analogous to dist-git. "test-git", I guess. I imagine 'fedpkg clone' being changed to check out both trees into a common directory, although there are a lot of possible implementations. I know you're just talking about whitelists at this point, but perhaps that could be the first step?
Another thing to consider — if you look at a buildSRPMFromSCM task, there are parameters like Build Tag and SCM URL — and the the git url should² include commit hash, even. I was _already_ wondering if we could find some way to include this in the RPM header, along with the koji task ID. This would probably be less disruptive than my ditch-the-dist-tag suggestion. :)
1.https://lists.fedoraproject.org/pipermail/devel/2014-January/194856.html 2. https://lists.fedoraproject.org/pipermail/buildsys/2015-June/004772.html
I've been excited for a while¹ about letting packagers (along with other test contributors) add tests to a git tree analogous to dist-git. "test-git", I guess. I imagine 'fedpkg clone' being changed to check out both trees into a common directory, although there are a lot of possible implementations. I know you're just talking about whitelists at this point, but perhaps that could be the first step?
This in the plans, and yes, it was supposed to be a small step forward in this direction :)
Another thing to consider — if you look at a buildSRPMFromSCM task, there are parameters like Build Tag and SCM URL — and the the git url should² include commit hash, even. I was _already_ wondering if we could find some way to include this in the RPM header, along with the koji task ID. This would probably be less disruptive than my ditch-the-dist-tag suggestion. :)
Placing information like these directly into RPM headers would be awesome. Is it technically possible? Does anyone know if there are any drawbacks to this approach (i.e. increased metadata size)? Would it be hard to implement?
On Tue, Jun 30, 2015 at 09:06:05AM -0400, Kamil Paral wrote:
I've been excited for a while¹ about letting packagers (along with other test contributors) add tests to a git tree analogous to dist-git. "test-git", I guess. I imagine 'fedpkg clone' being changed to check
This in the plans, and yes, it was supposed to be a small step forward in this direction :)
Nice. :)
Another thing to consider — if you look at a buildSRPMFromSCM task, there are parameters like Build Tag and SCM URL — and the the git url should² include commit hash, even. I was _already_ wondering if we could find some way to include this in the RPM header, along with the koji task ID. This would probably be less disruptive than my ditch-the-dist-tag suggestion. :)
Placing information like these directly into RPM headers would be awesome. Is it technically possible? Does anyone know if there are any drawbacks to this approach (i.e. increased metadata size)? Would it be hard to implement?
I'm sure it's technically possible. It would increase metadata size, but it doesn't seem like by a lot, and it seems like valuable metadata to me making it worth it. I don't know how hard it'd be, though. (I think the build system side would be easy, and adding support to RPM _seems_ easy, but we'd have to ask the actual RPM maintainers.)
On Tue, Jun 16, 2015 at 10:44:26 -0400, Martin Krizek mkrizek@redhat.com wrote:
According to [1], using a dist tag is mandatory. However there are quite a few packages [2] where a dist tag is missing. I am curious if those are bugs and should be filed. Or are there any exceptions that I am missing?
Some of those were large data sets for games. The idea was that when doing an upgrade between releases you could save downloading a large amount of data when there wasn't really a change. This cost isn't as bad now and there \ are some downsides to not having the dist tag. When I get involved with such games now, I add dist tags, but I haven't looked for these cases systematically.
"BW" == Bruno Wolff bruno@wolff.to writes:
BW> Some of those were large data sets for games. The idea was that when BW> doing an upgrade between releases you could save downloading a large BW> amount of data when there wasn't really a change.
Back then we could hardlink the same package into multiple repositories if it didn't change. Since we started signing each release with its own key back in the F8 era, this stopped being useful.
Dist tags should be added to everything except a very small set of exceptions. Seems to be a good job for some provenpackagers. I doubt it's worth filing bugs for these when it would just be quicker to fix them. If I had time today I'd just do them all, but ugh, FPC work and my package reviews have to come first.
- J<
Dist tags should be added to everything except a very small set of exceptions. Seems to be a good job for some provenpackagers. I doubt it's worth filing bugs for these when it would just be quicker to fix them. If I had time today I'd just do them all, but ugh, FPC work and my package reviews have to come first.
- J<
Based on this whole discussion (and on the packaging guidelines), I'm going to file bugs against all affected packages (I'm not a provenpackager myself). Thanks everyone for supplying helpful information.
Sorry, yes. I meant that the macro would not be available at build -time. But as Ralf pointed out, I suppose we could hard-code the value rather than use %{?dist}, which makes sense.
I'm not sure of any other specific rationale for not including the dist in the Release: field. CCing Dennis Gilmore to see if he knows the specifics.
I'm going to talk to Dennis about hardcoding that value in fedora-release if possible, or we're going to have an alternative logic about that particular package in libtaskotron.
Based on this whole discussion (and on the packaging guidelines), I'm going to file bugs against all affected packages (I'm not a provenpackager myself).
For the record, the list is here: https://bugzilla.redhat.com/show_bug.cgi?id=1237153
It does not cover fedora-release*, generic-release* and fedora-repos* at the moment.
On Tue, 30 Jun 2015 10:15:45 -0400 (EDT) Kamil Paral kparal@redhat.com wrote:
Based on this whole discussion (and on the packaging guidelines), I'm going to file bugs against all affected packages (I'm not a provenpackager myself).
For the record, the list is here: https://bugzilla.redhat.com/show_bug.cgi?id=1237153
It does not cover fedora-release*, generic-release* and fedora-repos* at the moment.
FYI, in the future could you use: https://fedoraproject.org/wiki/Mass_bug_filing for setting up things and answering all the questions maintainers might have up front?
thanks,
kevin
FYI, in the future could you use: https://fedoraproject.org/wiki/Mass_bug_filing for setting up things and answering all the questions maintainers might have up front?
thanks,
kevin
Thanks, I wasn't aware of that.
Btw, to increase that page discoverability, maybe it could be added to some categories (certainly at least Packaging, but maybe there's something like Packaging SOPs?) and/or link it from somewhere (it doesn't seem to be linked from anywhere).
On Tue, 7 Jul 2015 08:35:48 -0400 (EDT) Kamil Paral kparal@redhat.com wrote:
FYI, in the future could you use: https://fedoraproject.org/wiki/Mass_bug_filing for setting up things and answering all the questions maintainers might have up front?
thanks,
kevin
Thanks, I wasn't aware of that.
Btw, to increase that page discoverability, maybe it could be added to some categories (certainly at least Packaging, but maybe there's something like Packaging SOPs?) and/or link it from somewhere (it doesn't seem to be linked from anywhere). -- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
I added some categories, but not sure where to link it.
If you can see any obvious places, feel free.
kevin
Dne 30.6.2015 v 15:13 Kamil Paral napsal(a):
Sorry, yes. I meant that the macro would not be available at build -time. But as Ralf pointed out, I suppose we could hard-code the value rather than use %{?dist}, which makes sense.
I'm not sure of any other specific rationale for not including the dist in the Release: field. CCing Dennis Gilmore to see if he knows the specifics.
I'm going to talk to Dennis about hardcoding that value in fedora-release if possible, or we're going to have an alternative logic about that particular package in libtaskotron.
Could you share the ticket with us if you already created one? I am asking since there is %{load:<path>} macro in RPM [1] for some while already and instead of creating the macros.dist on the fly [2], it would be probably better to have it as a source, where the %dist tag is defined and just %load it into the fedora-release.spec.
Vít
[1] http://lists.rpm.org/pipermail/rpm-maint/2014-February/003659.html [2] http://pkgs.fedoraproject.org/cgit/fedora-release.git/tree/fedora-release.sp...
Could you share the ticket with us if you already created one? I am asking since there is %{load:<path>} macro in RPM [1] for some while already and instead of creating the macros.dist on the fly [2], it would be probably better to have it as a source, where the %dist tag is defined and just %load it into the fedora-release.spec.
Vít
I planned to ping him in person to simplify the discussion, but since you asked, I created a bugzilla ticket instead: https://bugzilla.redhat.com/show_bug.cgi?id=1238214
Please add any important details, if needed :-) Thank you.
On Tue, Jun 16, 2015 at 10:44:26AM -0400, Martin Krizek wrote:
According to [1], using a dist tag is mandatory. However there are quite a few packages [2] where a dist tag is missing. I am curious if those are bugs and should be filed. Or are there any exceptions that I am missing?
Soooo, going back a level... I see that there is a "DISTTAG" in RPM headers, but it's not set to anything in any of my installed packages.
What if we actually set this in the build system, and removed it from the Release field in all of our specfiles (with one big recursive sed script)? The filename generation could be changed to automatically add this, and query and sort operations also adjusted appropriately.
It's always been pretty hacky to overload one of the metadata fields with unrelated metadata.
"MM" == Matthew Miller mattdm@fedoraproject.org writes:
MM> What if we actually set this in the build system, and removed it MM> from the Release field in all of our specfiles (with one big MM> recursive sed script)?
Whether that would work would depend on whether we can actually rely on any particular behavior of RPM with regards to DISTTAG, across all supported RPM versions. (Unless we want to essentially ban people from having the same spec across various distro versions and EPEL, that is.)
Also, we need to consider how this would interact with people building with fedpkg local or even plain rpmbuild. I think it's important that those things at least give a close approximation to what you'd get out of the buildsys.
Otherwise, I certainly would be super happy to be able to purge that weird macro from our specs and docs.
- J<
On Wed, 2015-06-17 at 13:27 -0400, Matthew Miller wrote:
On Tue, Jun 16, 2015 at 10:44:26AM -0400, Martin Krizek wrote:
According to [1], using a dist tag is mandatory. However there are quite a few packages [2] where a dist tag is missing. I am curious if those are bugs and should be filed. Or are there any exceptions that I am missing?
Soooo, going back a level... I see that there is a "DISTTAG" in RPM headers, but it's not set to anything in any of my installed packages.
What if we actually set this in the build system, and removed it from the Release field in all of our specfiles (with one big recursive sed script)? The filename generation could be changed to automatically add this, and query and sort operations also adjusted appropriately.
1. Then you need to fix rpm/yum/dnf/libsolv to honor it for upgrades.
2. Then you need to fix rpm/yum/dnf/libsolv to parse it out of the specfile and honor it for conflicts/obsoletes/provides/requires.
3. Then you need to fix createrepo/createrepo-c, and the repodata, to work with #2.
4. Then you need to fix yum/dnf/etc. to optionally parse it out of the command line.
5. Then you need to fix koji.
6. Then you just need to fix the rest of the world.
On Thu, Jun 18, 2015 at 12:13:37PM -0400, James Antill wrote:
- Then you need to fix rpm/yum/dnf/libsolv to honor it for upgrades.
- Then you need to fix rpm/yum/dnf/libsolv to parse it out of the
specfile and honor it for conflicts/obsoletes/provides/requires. 3. Then you need to fix createrepo/createrepo-c, and the repodata, to work with #2. 4. Then you need to fix yum/dnf/etc. to optionally parse it out of the command line. 5. Then you need to fix koji. 6. Then you just need to fix the rest of the world.
Up until #6, it doesn't sound _that_ awful. :)
On Thu, Jun 18, 2015 at 12:13 PM, James Antill james@fedoraproject.org wrote:
On Wed, 2015-06-17 at 13:27 -0400, Matthew Miller wrote:
On Tue, Jun 16, 2015 at 10:44:26AM -0400, Martin Krizek wrote:
According to [1], using a dist tag is mandatory. However there are quite a few packages [2] where a dist tag is missing. I am curious if those are bugs and should be filed. Or are there any exceptions that I am missing?
Soooo, going back a level... I see that there is a "DISTTAG" in RPM headers, but it's not set to anything in any of my installed packages.
It's typically set for the build environemnt in /etc/rpm/macros.dist. That's built as part of the 'fedora-release' or similar OS release packages, and that seems a perfectly safe package to build up from a previous build environment first as part of the bootstrap process for new releases.
What if we actually set this in the build system, and removed it from the Release field in all of our specfiles (with one big recursive sed script)? The filename generation could be changed to automatically add this, and query and sort operations also adjusted appropriately.
Then you need to fix rpm/yum/dnf/libsolv to honor it for upgrades.
Then you need to fix rpm/yum/dnf/libsolv to parse it out of the
specfile and honor it for conflicts/obsoletes/provides/requires.
Why? If you're activating a dnf or yum repository for desired access, why would you want to segregate the 'dist' from other alphhanumeric fields? If you activate both Fedora 21 and Fedora 22 in your configs, for whatever reason, it's normally reasonable to assume that a .f23 is more recent and usable than a .f22.
It's only when updates or significant renaming exist for older operating systems than for newer operating systems, and you *cannot* hope to outsmart this kind of chaos. Attempts to outsmart this are, generally, doomed to failure becuase you cannot go back to old packages and make them be rebuilt with whatever hacked up workaround comes with newer versions.
- Then you need to fix createrepo/createrepo-c, and the repodata, to
work with #2.
Why? Why would you *ever* want to play max and match with multile 'dist' ettings in the same repository, and *not* obey normal dist versioning?
- Then you need to fix yum/dnf/etc. to optionally parse it out of the
command line.
Then you need to fix koji.
Then you just need to fix the rest of the world.
Again, why? This is normally *set* by the 'fedora-release' package. which should be one of the first packages built in the bootstrap procedure for new releases and can reasonably safely be bootstrap built. And it gets a major version version number update anyway, so it's not like there will be conflicts.
packaging@lists.fedoraproject.org