3:14 a.m.
It used to be a good practice to announce changes in Packaging Guidelines
<https://docs.fedoraproject.org/en-US/packaging-guidelines/> here on this
list. The forkflow was that Fedora Packaging Committee accepted a change on
it's meeting and then announced it in their meeting notes posted here. This
workflow allowed packagers to notice the changes and apply them to their
packages.
However, this is not true anomore. E.g. In February a ban for wildcard %files
was augmented from dynamic libraries to all top-level files
<https://pagure.io/packaging-committee/c/2bc90a6463ae591ed134955485da0596c...;:
commit 2bc90a6463ae591ed134955485da0596c2fe958b
Author: Carl George <carl(a)george.computer>
Date: Wed Feb 2 18:52:03 2022 -0600
Adapt Python's explicit lists guidance to the main guidelines
diff --git a/guidelines/modules/ROOT/pages/index.adoc
b/guidelines/modules/ROOT/pages/index.adoc
index 2bb4f9e..5ec0896 100644
--- a/guidelines/modules/ROOT/pages/index.adoc
+++ b/guidelines/modules/ROOT/pages/index.adoc
@@ -2574,6 +2574,27 @@ The %defattr directive in the %files list
SHOULD ONLY be used when setting a non-default value,
or to reset to the default value after having set a non-default value.
+=== Explicit lists
+
+Packagers *SHOULD NOT* simply glob everything under a shared directory.
+
+In particular, the following *SHOULD NOT* be used in `+%files+`:
+
+* `+%{_bindir}/*+`
+* `+%{_datadir}/*+`
+* `+%{_includedir}/*+`
+* `+%{_mandir}/*+`
+* `+%{_docdir}/*+`
To my surprise the first time when I get known to this new rule was today
in a review of my new package.
It could be that my memory failed. So I checked FPC and found these two
relevant issues:
<https://pagure.io/packaging-committee/pull-request/1160>
<https://pagure.io/packaging-committee/pull-request/1161>
Which do not contain any description or summary. Simply bunch of "+1"
comments. Then I searched a February archive of this list and found these
three FPC posts:
Schedule for Thursday's FPC Meeting (2022-02-03 17:00 UTC)
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Schedule for Thursday's FPC Meeting (2022-02-10 17:00 UTC)
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Schedule for Thursday's FPC Meeting (2022-02-17 17:00 UTC)
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
None of them mentions this change.
Could we please resume announcing substantial changes in the guidelines on
this mailing list?
-- Petr
12:50 a.m.
Petr Pisar wrote:
However, this is not true anomore. E.g. In February a ban for
wildcard
%files was augmented from dynamic libraries to all top-level files
<https://pagure.io/packaging-committee/c/2bc90a6463ae591ed134955485da0596c...;:
When will this silliness ever stop? It just does not make sense to
explicitly list every single file in the RPM. Wildcards are often the only
reasonable way.
It is already enough of a PITA that we are now forced to explicitly maintain
the soname for libraries in our specfiles. (I have always been opposed to
that. Soversions are the main thing for which I used to *always* use a
wildcard.)
Kevin Kofler
7:02 a.m.
While it is annoying to spell out each file it does catch package changes which might go
unnoticed otherwise. In particular, we've had a few unannounced soname changes and
such lately. [Disclaimer: I have not checked whether the maintainer ignored the build
failure for an explicit soname or got trapped by a wildcard in these cases.]
We could probably live better with wildcards if proper rpmdiff-tools were part of the
workflow and of gating or such. Those would be the right tool for the job.
7:08 a.m.
On Thu, Nov 3, 2022 at 12:02 PM Michael J Gruber <mjg(a)fedoraproject.org>
wrote:
While it is annoying to spell out each file it does catch package
changes
which might go unnoticed otherwise. In particular, we've had a few
unannounced soname changes and such lately. [Disclaimer: I have not checked
whether the maintainer ignored the build failure for an explicit soname or
got trapped by a wildcard in these cases.]
But the packaging guidelines already mentioned not globbing the soname part
of the files, so this change makes no difference to that use case.
Extending the no-globbing rule to other directories like datadir seems very
excessive. Why should we have to list all files a package wants to ship as
its data?
-Ian
We could probably live better with wildcards if proper rpmdiff-tools were
part of the workflow and of gating or such. Those would be the right tool
for the job.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
10:31 a.m.
On Thu, Nov 3, 2022 at 12:10 PM Ian McInerney via devel
<devel(a)lists.fedoraproject.org> wrote:
But the packaging guidelines already mentioned not globbing the
soname part of the files, so this change makes no difference to that use case. Extending
the no-globbing rule to other directories like datadir seems very excessive. Why should we
have to list all files a package wants to ship as its data?
The soname always (mostly) made sense since
it addressed one of the common issues of soname
bumps that were often missed that could impact
other packages (we still regularly get "unannounced
soname bump" emails, which suggests that that
package did not have an explicit soname spec;
I would hope one of the fixes in that case updated
the spec file to address the soname glob). Sure,
some packagers are very good about the entire
soname bump issue, but I believe that adding the
suspenders to the belt was not overly onerous.
On the other hand, executable and include files
are going to be interesting. I, for one, look forward
to seeing the response(s) from someone such as
the kernel packager who now SHOULD explicitly
identify all the include files in the kernel-headers
package (to pick on an obvious example).
10:56 a.m.
On Thu, 2022-11-03 at 15:31 +0000, Gary Buhrmaster wrote:
On Thu, Nov 3, 2022 at 12:10 PM Ian McInerney via devel
<devel(a)lists.fedoraproject.org> wrote:
> But the packaging guidelines already mentioned not globbing the soname part of the
files, so this change makes no difference to that use case. Extending the no-globbing rule
to other directories like datadir seems very excessive. Why should we have to list all
files a package wants to ship as its data?
The soname always (mostly) made sense since
it addressed one of the common issues of soname
bumps that were often missed that could impact
other packages (we still regularly get "unannounced
soname bump" emails, which suggests that that
package did not have an explicit soname spec;
I would hope one of the fixes in that case updated
the spec file to address the soname glob). Sure,
some packagers are very good about the entire
soname bump issue, but I believe that adding the
suspenders to the belt was not overly onerous.
On the other hand, executable and include files
are going to be interesting. I, for one, look forward
to seeing the response(s) from someone such as
the kernel packager who now SHOULD explicitly
identify all the include files in the kernel-headers
package (to pick on an obvious example).
Again, this is a misunderstanding of what the rule says. It does not at
all mean you have to list every file.
The kernel could probably be considered an exception, but even there,
if it were to comply with the rule, it would only need this:
/usr/include/asm*
/usr/include/drm
/usr/include/linux
/usr/include/misc
/usr/include/mtd
/usr/include/rdma
/usr/include/scsi
/usr/include/sound
/usr/include/video
/usr/include/xen
there, I did it for free. Took one minute.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
12:13 p.m.
On Thu, 3 Nov 2022 at 12:24, Gary Buhrmaster <gary.buhrmaster(a)gmail.com>
wrote:
On Thu, Nov 3, 2022 at 3:57 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> there, I did it for free. Took one minute.
Clearly it should be submitted as a PR to the kernel package.
And another for the glibc package (that
one likely will take more than a minute).
So glibc will be hard one because it has sections like:
```
%files -f langpack-]]..lang..[[.filelist langpack-]]..lang..[[
]]))
end
for i = 1, #locales do
lang_package(locales[i])
end
}
```
and
```
%files -f devel.filelist devel
%if %{glibc_autorequires}
%attr(0755,root,root) %{_rpmconfigdir}/glibc.req
%{_fileattrsdir}/glibc.attr
%endif
```
Looking through the spec files used for rawhide today.. there are 1242
packages which use %{bindir}/* with the bulk of them in golang and perl.
```
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_includedir}/\*' *spec | wc
-l
487
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_docdir}/\*' *spec | wc -l
6
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_mandir}/\*' *spec | wc -l
417
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_bindir}/\*' *spec | wc -l
1242
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_datadir}/\*' *spec | wc -l
3
```
the two small sets are like
```
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_datadir}/\*' *spec
gawk.spec:%{_datadir}/*awk
gnome-pomodoro.spec:%{_datadir}/*/org.gnome.Pomodoro.appdata.xml
htmlcxx.spec:%{_datadir}/*
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_docdir}/\*' *spec
acpica-tools.spec:%{_docdir}/*/*
assimp.spec:%{_docdir}/*
freecell-solver.spec:%{_docdir}/*
prboom-plus.spec:%{_docdir}/*
sblim-sfcc.spec:%{_docdir}/*
vmod-querystring.spec:%{_docdir}/*
```
I am guessing the pomodoro would be ok and the others should be easyfix.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
12:36 p.m.
On Thu, 3 Nov 2022 at 12:24, Gary Buhrmaster
<gary.buhrmaster(a)gmail.com>
wrote:
...
ssmoogen@ssmoogen-rh:~/GPG/rpm-specs$ egrep '^%{_mandir}/\*'
*spec | wc -l
417
I think that for `%{_mandir}` each subdir should be accounted separately:
```
for i in 1 2 3 4 5 6 7; do echo "%{_mandir}/man$i/* $(egrep
'^%{_mandir}/man'$i'/\*' *.spec|wc -l)"; done
%{_mandir}/man1/* 896
%{_mandir}/man2/* 3
%{_mandir}/man3/* 2405
%{_mandir}/man4/* 4
%{_mandir}/man5/* 108
%{_mandir}/man6/* 25
%{_mandir}/man7/* 47
```
Sergey
3:10 a.m.
* Stephen Smoogen:
On Thu, 3 Nov 2022 at 12:24, Gary Buhrmaster
<gary.buhrmaster(a)gmail.com> wrote:
On Thu, Nov 3, 2022 at 3:57 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> there, I did it for free. Took one minute.
Clearly it should be submitted as a PR to the kernel package.
And another for the glibc package (that
one likely will take more than a minute).
So glibc will be hard one because it has sections like:
```
%files -f langpack-]]..lang..[[.filelist langpack-]]..lang..[[
]]))
end
for i = 1, #locales do
lang_package(locales[i])
end
}
```
and
```
%files -f devel.filelist devel
%if %{glibc_autorequires}
%attr(0755,root,root) %{_rpmconfigdir}/glibc.req
%{_fileattrsdir}/glibc.attr
%endif
```
Another hard one is rust, which has hashed sonames like
/usr/lib64/libstd-09076360fd960627.so. The hash is only known after
building the package because that fixes the ephemeral ABI.
Thanks,
Florian
2:30 p.m.
On 11/4/22 1:10 AM, Florian Weimer wrote:
Another hard one is rust, which has hashed sonames like
/usr/lib64/libstd-09076360fd960627.so. The hash is only known after
building the package because that fixes the ephemeral ABI.
Right... I could glob a little more specifically for the few libXYZ-*.so
prefixes I'm expecting, but the hash intentionally changes.
(There's also an explicit __provides_exclude to hide them.)
3:16 p.m.
On Fri, 2022-11-04 at 09:10 +0100, Florian Weimer wrote:
* Stephen Smoogen:
> On Thu, 3 Nov 2022 at 12:24, Gary Buhrmaster <gary.buhrmaster(a)gmail.com>
wrote:
>
> On Thu, Nov 3, 2022 at 3:57 PM Adam Williamson
> <adamwill(a)fedoraproject.org> wrote:
>
> > there, I did it for free. Took one minute.
>
> Clearly it should be submitted as a PR to the kernel package.
>
> And another for the glibc package (that
> one likely will take more than a minute).
>
> So glibc will be hard one because it has sections like:
> ```
> %files -f langpack-]]..lang..[[.filelist langpack-]]..lang..[[
> ]]))
> end
>
> for i = 1, #locales do
> lang_package(locales[i])
> end
> }
> ```
> and
> ```
> %files -f devel.filelist devel
> %if %{glibc_autorequires}
> %attr(0755,root,root) %{_rpmconfigdir}/glibc.req
> %{_fileattrsdir}/glibc.attr
> %endif
> ```
Another hard one is rust, which has hashed sonames like
/usr/lib64/libstd-09076360fd960627.so. The hash is only known after
building the package because that fixes the ephemeral ABI.
That's not affected by the changed guideline in this case, though. It
would come under the existing one about not using wildcards for
sonames. This would see like a reasonable exception to that guideline.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
10:47 a.m.
On Thu, 2022-11-03 at 12:08 +0000, Ian McInerney via devel wrote:
On Thu, Nov 3, 2022 at 12:02 PM Michael J Gruber
<mjg(a)fedoraproject.org>
wrote:
> While it is annoying to spell out each file it does catch package changes
> which might go unnoticed otherwise. In particular, we've had a few
> unannounced soname changes and such lately. [Disclaimer: I have not checked
> whether the maintainer ignored the build failure for an explicit soname or
> got trapped by a wildcard in these cases.]
>
But the packaging guidelines already mentioned not globbing the soname part
of the files, so this change makes no difference to that use case.
Extending the no-globbing rule to other directories like datadir seems very
excessive. Why should we have to list all files a package wants to ship as
its data?
You don't. You can use less general wildcards. Just don't wildcard
absolutely everything in the directory. If the project is putting
dozens of files that don't contain something obviously usable for a
more specific wildcard - like the project's name - *directly* into one
of those directories (the rule doesn't forbid you including an entire
subdirectory, note) - that in itself is a bad idea that you as the
packager ought to be aware of and keep an eye on to make sure it
doesn't unnecessarily conflict with other packages.
The rule comes with an explanation:
"This rule serves as a check against common mistakes
which are otherwise hard to detect.
It does limit some possibilities for automation.
The most common mistake this rule prevents is upstream adding new
commands in `+%{_bindir}/*+`.
You should always check such changes for
https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_com...
,
and keep the list of such files explicit and auditable."
I agree it should have been announced, though.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
7:11 a.m.
On Thu, 3 Nov 2022 at 08:02, Michael J Gruber <mjg(a)fedoraproject.org> wrote:
While it is annoying to spell out each file it does catch package
changes
which might go unnoticed otherwise. In particular, we've had a few
unannounced soname changes and such lately. [Disclaimer: I have not checked
whether the maintainer ignored the build failure for an explicit soname or
got trapped by a wildcard in these cases.]
Or they will just do what I used to do long ago and just do a temp spec
file with some sort of `%files *` and then rpm -ql and then `rpm -ql | sed`
and replace the data in the pushed spec with the list. Nothing is caught
because few people have time for the several hundred packages they are
maintaining.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
11:01 a.m.
On Thu, Nov 3, 2022 at 12:12 PM Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
Or they will just do what I used to do long ago and just do a temp
spec file with some sort of `%files *` and then rpm -ql and then `rpm -ql | sed` and
replace the data in the pushed spec with the list. Nothing is caught because few people
have time for the several hundred packages they are maintaining.
As I recall(*), there are spec files that just
find the various installed files (categorized
as needed), and then use the -f option
on the %files section. Which, technically,
meets the requirements, while not dealing
with the intent at all. I think this is really
a question of scale. For smaller packages
with a small number of expected files,
listing them explicitly is going to be a
smaller burden to add or maintain, but for
larger packages (arguably exactly the
ones that are more likely to "stomp" on
other files and you want to catch changes
for), the work is likely much higher (to the
point that one adds in automation to hide
the work).
(*) I think glibc is an example, but it
has been some time since I looked.
11:07 a.m.
On 03/11/2022 17:01, Gary Buhrmaster wrote:
As I recall(*), there are spec files that just
find the various installed files (categorized
as needed), and then use the -f option
on the %files section.
IMO, such behavior should be strictly prohibited.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
11:22 a.m.
On Thu, 2022-11-03 at 17:07 +0100, Vitaly Zaitsev via devel wrote:
On 03/11/2022 17:01, Gary Buhrmaster wrote:
> As I recall(*), there are spec files that just
> find the various installed files (categorized
> as needed), and then use the -f option
> on the %files section.
IMO, such behavior should be strictly prohibited.
I would say the guidelines assume good faith in general, so it should
be considered as kind of implicit that it's not OK to do weird things
whose sole intent is to get around the strict wording of a guideline
but achieve the effect the guideline is trying to avoid.
Otherwise the guidelines will start to look like criminal statutes and
be about as long, which I don't think anyone wants.
It has already been noted this is a SHOULD guideline, not a MUST
guideline, which means it's not a hard requirement in any case, and if
there are cases where a wildcard is clearly the least worst choice it's
probably OK.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
8:25 a.m.
Vitaly Zaitsev via devel wrote:
On 03/11/2022 17:01, Gary Buhrmaster wrote:
> As I recall(*), there are spec files that just
> find the various installed files (categorized
> as needed), and then use the -f option
> on the %files section.
IMO, such behavior should be strictly prohibited.
Congratulations, you have just banned %find_lang…
There are cases where automatically generating a file list is clearly the
most reasonable solution, and we even have macros for that (e.g., %find_lang
and some KDE-specific variants of the concept). (Hint: A wildcard would
actually be wrong to use there because it misses the %lang(…) tags that the
macro automatically adds. And you really do not want to have to list every
single language manually, and update the list for every single new upstream
release, since translations come and go.)
Kevin Kofler
11:17 a.m.
On Thu, Nov 03, 2022 at 04:01:58PM +0000, Gary Buhrmaster wrote:
On Thu, Nov 3, 2022 at 12:12 PM Stephen Smoogen
<ssmoogen(a)redhat.com> wrote:
> Or they will just do what I used to do long ago and just do a temp spec file with
some sort of `%files *` and then rpm -ql and then `rpm -ql | sed` and replace the data in
the pushed spec with the list. Nothing is caught because few people have time for the
several hundred packages they are maintaining.
As I recall(*), there are spec files that just
find the various installed files (categorized
as needed), and then use the -f option
on the %files section. Which, technically,
meets the requirements, while not dealing
with the intent at all. I think this is really
a question of scale. For smaller packages
with a small number of expected files,
listing them explicitly is going to be a
smaller burden to add or maintain, but for
larger packages (arguably exactly the
ones that are more likely to "stomp" on
other files and you want to catch changes
for), the work is likely much higher (to the
point that one adds in automation to hide
the work).
I don't think that the scale question is a big factor here
because this is a one-time hit when creating the spec. If a
package install 1000 files into %{_bindir} or %{_includedir}
by all means use a script to automate the filling of %files
without wildcards, when first authoring the spec file.
On subsequent updates to new releases, the projects are not going
to be adding/removing huge numbers of files in these directories.
You'll be looking out for a small number of changes, just like any
other package regardless of scale.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
10:26 a.m.
On Thu Nov 3, 2022 at 06:50 +0100, Kevin Kofler via devel wrote:
When will this silliness ever stop? It just does not make sense to
explicitly list every single file in the RPM. Wildcards are often the only
reasonable way.
Nobody is saying that you have to list every single file in the package
or that e.g. adding `%{_datadir}/%{name}/` to %files is prohibited. It
is simply not allowed to glob absolutely everything under a shared
directory. For instance, ansible-core installs 11 different binaries
into %{_bindir} that all start with `ansible` that would be tedious to
list out manually. Instead of globing all of %{_bindir} with
`%{_bindir}/*, I could add `%{_bindir}/ansible*` which complies with
this guideline and is just as simple.
I think this is a sensible rule as it prevents conflicts and other
issues from popping up on updates when a package's build scripts start
installing new files. When reviewing Go packages, I've caught multiple
issues with `%{_bindir}/*` globs that hide conflicting files and/or
test/utility binaries that shouldn't be shipped to begin with.
Unfortunately, go2rpm generates specfiles with these globs by default.
FWIW, this is a SHOULD guideline not a MUST guideline, but I don't see a
case where such broad globs are justifiable.
As for the other complaint, I subscribe to the FPC issue tracker[1] to
to keep up with guidelines changes. There's also the packaging list, but
not a lot of active discussion happens there. I agree that it would be
beneficial to make changes more visible.
[1]: https://pagure.io/packaging-committee
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
11:06 a.m.
On Thu, 3 Nov 2022 at 11:26, Maxwell G via devel <
devel(a)lists.fedoraproject.org> wrote:
On Thu Nov 3, 2022 at 06:50 +0100, Kevin Kofler via devel wrote:
> When will this silliness ever stop? It just does not make sense to
> explicitly list every single file in the RPM. Wildcards are often the
only
> reasonable way.
Nobody is saying that you have to list every single file in the package
or that e.g. adding `%{_datadir}/%{name}/` to %files is prohibited. It
is simply not allowed to glob absolutely everything under a shared
directory. For instance, ansible-core installs 11 different binaries
into %{_bindir} that all start with `ansible` that would be tedious to
list out manually. Instead of globing all of %{_bindir} with
`%{_bindir}/*, I could add `%{_bindir}/ansible*` which complies with
this guideline and is just as simple.
I read the section twice before posting, and because there were no examples
countering it and the text for why it was done said
`The most common mistake this rule prevents is upstream adding new commands
in %{_bindir}/*.`
I came to the conclusion that even `%{bindir}/ansible*` would be against
this as you would still miss
a) if ansible-foobaz had been added to the package when it had not been
there before
b) if ansible-foobaz was in a different package and you have an
unintentional conflict.
In either case, the only fix would be to explicitly list out every filename
each time so you were aware that things had been added or removed. I am not
sure how to better word this to escape this confusion but having a working
counterexample of saying `%{bindir}/ansible*` is ok would probably help.
At the moment the biggest set of packages that need cleanup will be perl,
golang and then about a couple hundred library rpms.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
12:22 p.m.
On Thu, Nov 3, 2022 at 4:07 PM Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
At the moment the biggest set of packages that need cleanup will be
perl, golang and then about a couple hundred library rpms.
I would think that the man api definitions may
be the most interesting for some libraries
(many files, sometimes un-glob-able by any
sort of prefix selection even if that is considered
to be allowed).
8:28 a.m.
Stephen Smoogen wrote:
I came to the conclusion that even `%{bindir}/ansible*` would be
against
this as you would still miss
a) if ansible-foobaz had been added to the package when it had not been
there before
b) if ansible-foobaz was in a different package and you have an
unintentional conflict.
I think the concern is not about Ansible suddenly adding, e.g.,
%{bindir}/ansible-cp, but about them suddenly adding, e.g., %{bindir}/cp.
Kevin Kofler
5:53 a.m.
On Wed, 2 Nov 2022 at 05:04, Petr Pisar <ppisar(a)redhat.com> wrote:
It used to be a good practice to announce changes in Packaging
Guidelines
<https://docs.fedoraproject.org/en-US/packaging-guidelines/> here on this
list. The forkflow was that Fedora Packaging Committee accepted a change on
it's meeting and then announced it in their meeting notes posted here. This
workflow allowed packagers to notice the changes and apply them to their
packages.
....
+=== Explicit lists
+
+Packagers *SHOULD NOT* simply glob everything under a shared
directory.
+
+In particular, the following *SHOULD NOT* be used in `+%files+`:
+
+* `+%{_bindir}/*+`
+* `+%{_datadir}/*+`
+* `+%{_includedir}/*+`
+* `+%{_mandir}/*+`
+* `+%{_docdir}/*+`
To my surprise the first time when I get known to this new rule was today
in a review of my new package.
Ugh changes like that really need a bit more open discussion and they need
to be announced here. What is the problem trying to be solved by this? Does
this solution actually solve that problem or band-aid it?
That said, it isn't like I as a packager have been following the packaging
committee enough to actually know what is going on. I have just taken it
for granted that they would just do what I felt was the right thing without
telling them that. Nor have I run for the packaging committee or spent time
dealing with the crap that trying to deal with N factorial combinations of
languages requires.
So what is the right way to deal with this? Have more people join the
packaging list and start asking questions?
On this rule, I am not sure how large packages are going to work. My guess
would be that some packager will come up with a script which just does the
glob, and then outputs the data in a list which is then sed back to be
`%{FOOdir}/blah1 %{FOOdir}/blah2 etc` And the problem trying to be solved
of stuff getting added in without review.. will just go out the door.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
9:12 a.m.
Dne 03. 11. 22 v 11:53 Stephen Smoogen napsal(a):
Ugh changes like that really need a bit more open discussion and they
need to be announced here.
I disagree. **Every** change should be announced here. I did enjoy them in past:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Can the FEPCO resume sending these emails?
Miroslav
6:23 a.m.
There was no response from any FPC member as far as I can tell,
therefore I have opened FPC ticket with the same request:
https://pagure.io/packaging-committee/issue/1232
Vít
Dne 02. 11. 22 v 9:14 Petr Pisar napsal(a):
It used to be a good practice to announce changes in Packaging
Guidelines
<https://docs.fedoraproject.org/en-US/packaging-guidelines/> here on this
list. The forkflow was that Fedora Packaging Committee accepted a change on
it's meeting and then announced it in their meeting notes posted here. This
workflow allowed packagers to notice the changes and apply them to their
packages.
However, this is not true anomore. E.g. In February a ban for wildcard %files
was augmented from dynamic libraries to all top-level files
<https://pagure.io/packaging-committee/c/2bc90a6463ae591ed134955485da0596c...;:
commit 2bc90a6463ae591ed134955485da0596c2fe958b
Author: Carl George <carl(a)george.computer>
Date: Wed Feb 2 18:52:03 2022 -0600
Adapt Python's explicit lists guidance to the main guidelines
diff --git a/guidelines/modules/ROOT/pages/index.adoc
b/guidelines/modules/ROOT/pages/index.adoc
index 2bb4f9e..5ec0896 100644
--- a/guidelines/modules/ROOT/pages/index.adoc
+++ b/guidelines/modules/ROOT/pages/index.adoc
@@ -2574,6 +2574,27 @@ The %defattr directive in the %files list
SHOULD ONLY be used when setting a non-default value,
or to reset to the default value after having set a non-default value.
+=== Explicit lists
+
+Packagers *SHOULD NOT* simply glob everything under a shared directory.
+
+In particular, the following *SHOULD NOT* be used in `+%files+`:
+
+* `+%{_bindir}/*+`
+* `+%{_datadir}/*+`
+* `+%{_includedir}/*+`
+* `+%{_mandir}/*+`
+* `+%{_docdir}/*+`
To my surprise the first time when I get known to this new rule was today
in a review of my new package.
It could be that my memory failed. So I checked FPC and found these two
relevant issues:
<https://pagure.io/packaging-committee/pull-request/1160>
<https://pagure.io/packaging-committee/pull-request/1161>
Which do not contain any description or summary. Simply bunch of "+1"
comments. Then I searched a February archive of this list and found these
three FPC posts:
Schedule for Thursday's FPC Meeting (2022-02-03 17:00 UTC)
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Schedule for Thursday's FPC Meeting (2022-02-10 17:00 UTC)
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
Schedule for Thursday's FPC Meeting (2022-02-17 17:00 UTC)
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
None of them mentions this change.
Could we please resume announcing substantial changes in the guidelines on
this mailing list?
-- Petr
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
508
days inactive
538
days old
25 comments
15 participants
participants (15)
-
Adam Williamson -
Daniel P. Berrangé -
Florian Weimer -
Gary Buhrmaster -
Ian McInerney -
Josh Stone -
Kevin Kofler -
Maxwell G -
Michael J Gruber -
Miroslav Suchý -
Petr Pisar -
Sergey Mende -
Stephen Smoogen -
Vitaly Zaitsev -
Vít Ondruch