Hi all ! I found out that one macro as described in our wiki is "almost" useless. > https://wiki.mageia.org/en/Packagers_RPM_tutorial#.rpmmacros_file_creation the macro : %distsuffix is used to define the macro %dist during the build time > http://svnweb.mageia.org/packages/updates/8/mageia-release/current/SPECS/mageia-release.spec?view=markup#l206 and %dist is not "variable dependent" afterwards. So suggesting to set %distsuffix in the .rpmmacros makes no sense. > $ rpm --showrc | grep %distsuffix > -13: __dist_ident %{?distsuffix:%distsuffix}%{?!distsuffix:.mga}%{?distro_release:%distro_release} > > $ rpm --showrc | grep %__dist_ident > -13: mkrel(c:) %{-c: 0.%{-c*}.}%{1}%{?subrel:.%subrel}%{?dist:%dist}%{?!dist:%__dist_ident}%([ "%{__distro_section}" != "core" ] && echo .%__distro_section) > > $ rpm --showrc | grep %mkrel I think this line : > http://svnweb.mageia.org/packages/updates/8/mageia-release/current/SPECS/mageia-release.spec?view=markup#l207 should be : > %%dist %%{distsuffix}%%{distro_release} another work arround (but why) is to redefine %dist in the .rpmmacros.
Thank you for the observation. Unsure where to assign this; start with MageiaTools.
CC: (none) => sysadmin-bugsSource RPM: mageia-release(-common) => mageia-release-8-3.mga8.src.rpmComponent: RPM Packages => Release (media or process)Assignee: bugsquad => mageiatools
This is actually intentional. It is not intended that "%dist" be redefined by components like that. Instead, you should override "%dist" itself for your own purposes. Actually, the "%dist" macro implementation should probably just be simplified to ".mga%{mageia}".
CC: (none) => ngompa13
This is just a regular package issue, so I'll switch it back to that.
Component: Release (media or process) => RPM PackagesAssignee: mageiatools => bugsquad
This look like duplicate of #20877 Also https://forums.mageia.org/en/viewtopic.php?f=10&t=12084 , link to that bug
Hi Katnatek, you are right, I badly searched. Should we close as duplicate ? Hi Neal, can you argue why: > is not intended that "%dist" be redefined by components ?
the goal here is that the users can redefine the rpm extension locally without touching system files. if i want .neo9 for exemple. If this is not possible anymore then this is a bug.
CC: (none) => mageia
(In reply to Nicolas Lécureuil from comment #6) > the goal here is that the users can redefine the rpm extension locally > without touching system files. > > if i want .neo9 for exemple. > > If this is not possible anymore then this is a bug. That's always possible: echo "%dist .neo%{mageia}" >> ~/.rpmmacros The value set in /usr/lib/rpm/macros.d/macros.dist can be overridden by the user easily enough.
(In reply to Jybz from comment #5) > Hi Katnatek, you are right, I badly searched. Should we close as duplicate ? > > Hi Neal, can you argue why: > > is not intended that "%dist" be redefined by components > ? The value in the %dist macro in /usr should be absolutely fixed, since it's essentially a branding macro set in mageia-release. If you want to override it yourself, replacing that value can be done in /etc/rpm/macros or ~/.rpmmacros. We also should generally avoid implicit dependency loops on macros, so macros that are part of Mageia branding should not loop back on stuff in rpm-setup. That's why the macros in rpm-setup depend on the macro in branding and not the other way around.
(In reply to Neal Gompa from comment #7) > (In reply to Nicolas Lécureuil from comment #6) > > the goal here is that the users can redefine the rpm extension locally > > without touching system files. > > > > if i want .neo9 for exemple. > > > > If this is not possible anymore then this is a bug. > > That's always possible: > > echo "%dist .neo%{mageia}" >> ~/.rpmmacros > > The value set in /usr/lib/rpm/macros.d/macros.dist can be overridden by the > user easily enough. perfect. Works for me.
> The value in the %dist macro in /usr should be absolutely fixed, since it's essentially a branding macro set in mageia-release. I still don't get why "absolutely fixed". The logic of variable is made exactly for it, %dist is composed from %distsuffix%distro_release > We also should generally avoid implicit dependency loops on macros, so macros that are part of Mageia branding should not loop back on stuff in rpm-setup. Where is the loop ? http://svnweb.mageia.org/packages/cauldron/rpm-mageia-setup/current/SPECS/rpm-mageia-setup.spec?annotate=1711497 distsuffix is not mentioned in rpm-mageia-setup (except the line defining %dist if not exists and distsuffix for the same case. %dist is "hardcoded" here /usr/lib/rpm/macros.d/macros.dist and %distsuffix is also hardcoded here /usr/lib/rpm/macros.d/macros.Default (or here http://svnweb.mageia.org/packages/updates/8/mageia-release/current/SPECS/mageia-release.spec?view=markup#l261 or more precisely l143) if %dist is "softcoded" with %distsuffix (which makes sense), it does not (or I didn't find it) loop to rpm-mageia-setup.
So I did a try, as root > cd /usr/lib/rpm/macros.d/ > mv macros.dist ../ as user > echo "%distsuffix .mgajibz%" >> ~/.rpmmacros > [jybz@localhost rpmbuild]$ rpm --eval %dist > %dist > [jybz@localhost rpmbuild]$ rpm --eval %distsuffix > .mgajibz > rpmbuild -ba ./SPECS/rogauracore.spec > [...] > Écrit : /home/jybz/rpmbuild/SRPMS/rogauracore-1.2-1.mgajibz8.src.rpm it confirms that %dist is defined if not existing with variables at build time with rpm-mageia-setup. I dig with distsuffix : > $ rpm --showrc | grep distsuffix > -13: __dist_ident %{?distsuffix:%distsuffix}%{?!distsuffix:.mga}%{?distro_release:%distro_release} > -13: distsuffix .mgajibz is it used in __dist_ident . > $ rpm --showrc | grep __dist_ident > -13: __dist_ident %{?distsuffix:%distsuffix}%{?!distsuffix:.mga}%{?distro_release:%distro_release} > -13: mkrel(c:) %{-c: 0.%{-c*}.}%{1}%{?subrel:.%subrel}%{?dist:%dist}%{?!dist:%__dist_ident}%([ "%{__distro_section}" != "core" ] && echo .%__distro_section) And __dist_ident is used only if %dist is not existing, which is not anymore the case as it ALWAYS exists (hardcoded, or generated in buildtime process with rpm-mageia-setup). So, __dist_ident is currently useless, unused variable. Event if %dist does not exists, as it is defined at the build time, made of distsuffix, then the statement %{?!dist:%__dist_ident} will always be false, and __dist_ident never used at all, any case.
There's definitely some cleanup that needs to be done here. Some of this stuff hasn't been looked over in the past few years. It's on my todo list to do some cleanup here in the coming weeks.
(In reply to Jybz from comment #10) > > The value in the %dist macro in /usr should be absolutely fixed, since it's essentially a branding macro set in mageia-release. > I still don't get why "absolutely fixed". The logic of variable is made > exactly for it, %dist is composed from %distsuffix%distro_release > It was composed this way to bootstrap the value when %mageia didn't exist, but it has existed for three Mageia releases now, so we can and should remove the macro dependency loop here.
(In reply to Neal Gompa from comment #13) > (In reply to Jybz from comment #10) > > > The value in the %dist macro in /usr should be absolutely fixed, since it's essentially a branding macro set in mageia-release. > > I still don't get why "absolutely fixed". The logic of variable is made > > exactly for it, %dist is composed from %distsuffix%distro_release > > > > It was composed this way to bootstrap the value when %mageia didn't exist, > but it has existed for three Mageia releases now, so we can and should > remove the macro dependency loop here. Actually, I'm mistaken here. The usage of %distsuffix and %distro_release are strictly defined from within the spec file itself, so it's not a dependency loop and it is explicitly intended to be fully resolved within the spec file. So the current behavior is correct and not a bug.
It looked to pe at the start that this 'bug' was more an academic question than one of any disfunctionment. Both Nicolas and (especially) Neal confirm that the status quo is OK. Neal's hope to tidy this area should please Jybz. Closing this; but if Jybz can demonstrate any malfunction, please feel free to re-open it.
Status: NEW => RESOLVEDResolution: (none) => WORKSFORME
However, the documentation has to be amended to reflect this (not so) new behaviour? It says: # distribution name suffix override #%distsuffix mga Should it be: # distribution suffix override #%dist mga ?
CC: (none) => yves.brungard_mageia
(In reply to papoteur from comment #16) > However, the documentation has to be amended to reflect this (not so) new > behaviour? > > It says: > > # distribution name suffix override > #%distsuffix mga > > Should it be: > > # distribution suffix override > #%dist mga > > ? Yes, and a bit more, see this mail: ========================================================================== -------- Doorgestuurd bericht -------- Onderwerp: Re: [dev] %distsuffix ignored? Datum: Thu, 19 Nov 2015 16:18:27 -0500 Van: Neal Gompa <ngompa13@gmail.com> Antwoord-naar: dev@ml.mageia.org Aan: dev@ml.mageia.org On Thu, Nov 19, 2015 at 3:13 PM, Atilla Öntaş <tarakbumba@gmail.com> wrote: > Today i noticed that %distsuffix macro is ignored from my .rpmmacros > file. I found that this is caused by this commit: > > > http://gitweb.mageia.org/software/rpm/rpm-setup/commit/?id=d396ea35d9d445fab46a9dcbad7c14b59b005095 > > So, is it a bug or we should define %dist macro in .rpmmacros from now > on? Notice that if %dist is defined than it is used as %distsuffix but > unlike %distsuffix we lost %distro_release: > > Before above commit : %distsuffix .trk ===> foo-1.0-1.trk6.i586 > > After above commit: %dist .trk ===> foo-1.0-1.trk.i586 > > Possible solution: %dist .trk%{distro_release} ===> foo-1.0-1.trk6.i586 > Yes, defining "%dist .trk%{distro_release}" in your .rpmmacros is the right way to go. ============================================================================ Apart from that, another thing that likely didn't get documented, is that using "mga" as distuffix for packages that aren't built by Mageai's build system, makes life for BugSquad and QA team harder, there were threads about that on Council and Dev ml, but we forgot to make an official decision after the last mail https://ml.mageia.org/l/arc/council/2019-09/msg00012.html : ============================================================================= -------- Doorgestuurd bericht -------- Onderwerp: Re: [council] [dev] [RFC] dist(suffix) "for_mga" for unoffical Mageia packages? Datum: Tue, 24 Sep 2019 03:18:26 -0400 Van: "David W. Hodgins" (via council Mailing List) <council@ml.mageia.org> Antwoord-naar: council@ml.mageia.org Aan: council@ml.mageia.org, Marja van Waes <marja11@xs4all.nl> On Tue, 24 Sep 2019 01:45:24 -0400, Marja van Waes <marja11@xs4all.nl> wrote: > Op 22-09-2019 om 21:22 schreef "David W. Hodgins" (via council Mailing > List): >> On Sun, 22 Sep 2019 08:42:25 -0400, Marja van Waes <marja11@xs4all.nl> >> wrote: >> >>> I'm absolutely against letting them use .mga like we do. It is so easy >>> to forget where a package came from, we can't rely on users telling us. >>> >>> However, it is not clear to me whether you're against allowing them to >>> use ".for_mga". >> >> That would be fine by me. Anything other then .mga would avoid the problem >> when it shows up in bug reports. >> >> Regards, Dave Hodgins > > > So, IIUC, for unofficial packages, you'd be fine with e.g.: > > rpm-4.15.0-1.for_mga8 > > and with > > rpm-4.15.0-1.xyz_mga8 > > But not fine with: > > rpm-4.15.0-1.mga8.xyz > > nor with > > rpm-4.15.0-1.mga8_xyz > > nor with > > rpm-4.15.0-1.xyz.mga8 > > > Is that correct? Yes, as long as there is something in the rpm package name that makes it clear in bug reports etc, that it's not actually from Mageia. Regards, Dave Hodgins ============================================================================
Resolution: WORKSFORME => (none)Assignee: bugsquad => doc-bugsStatus: RESOLVED => REOPENEDCC: (none) => marja11
Hi papoteur, it should be either : > %distsuffix .mga_whatever > %dist %distsuffix%distro_release or directly : > %dist .mga_whatever%distro_release I'm most in favor of version 1, with : > %distsuffix .mga$USER > %dist %distsuffix%distro_release in such way, %dist is not hardcoded anymore like before, but the scheme remains, and the macro %distsuffix is like documented working. I like using .mga$USER, which is automatically resolved.
Ok, it isn't well said, I like using : > echo "%distsuffix .mga$USER" >>~/.rpmmacros which is automatically replaced with bash to the current user. Which makes for example with me : %distsuffix .mgajybz and give a rpm name like : ktechlab-0.50.0-1.mgajibz8.x86_64.rpm In this way, it is clear that it is for mga8 and it isn't an official package.
Done.
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED
*** Bug 20877 has been marked as a duplicate of this bug. ***
CC: (none) => j.alberto.vc
(In reply to Jybz from comment #19) > In this way, it is clear that it is for mga8 and it isn't an official > package. I prefer with the version after the distribution name. %dist %{distsuffix}%{mageia}geex But the wiki is not very clear: >Note: >Using "mga" as distuffix for packages that aren't built by Mageia's build >system, makes life for BugSquad and QA team harder. This is a good practice to >change it If one changes only %distsuffix it does nothing at the package name.
CC: (none) => geex+mageia
Yes, %dist is hardcoded, it is required to change it manually. It has been decided to not fix.
Resolution: FIXED => WONTFIX
Sorry, I don't understand FIXED or WONTFIX here. I'm trying to getting used with the new ways, I've been away from packaging since 10+ years. There's nothing but the wiki to fix iiuc. It's already assigned to "Documentation Team", but maybe this is a different thing.
I just modify the resulotion flag from fixed (actually nothing is fixed, %dist is still hardcoded and %{distsuffix} is an orphan unused variable. Yes, you have to redefine %dist if you want to change the package naming. It is assign to doc team because the documentation mentioned the distsuffix (did not checked if done or not).
In these times (long ago, maybe in the previous millenium), when someone rebuilt a package there was a mention "custom" added, does this still work ? I compiled a kernel 6.2.11 with CONFIG_LOCALVERSION="-geex" but not turned it into a package. Maybe it only worked with kernel packages ?