8:42 a.m.
In order to define the Base WG core package group and minimize minimal
installations for e.g. cloud images and the atomic spin, I created some
dependency lists:
There are so many definitions of minimum sets:
systemd: container boot
systemd + bash + login: container boot with login
systemd + kernel + bootloader + dracut: machine boot
systemd + ... + sshd + firewalld: network minimal
Here is a little script to generate the filelist (which apparently is extended
by dnf and kickstart with other default packages):
<https://harald.fedorapeople.org/pkgset/pkgset.sh>
So, if we start with systemd, then we'll get 112 packages at least for rawhide.
systemd (112 pkgs):
<https://harald.fedorapeople.org/pkgset/f24-systemd-requires.txt>
systemd+kernel+grub2+grub2-efi+grubby+dracut (142 pkgs):
<https://harald.fedorapeople.org/pkgset/f24-systemd-kernel-requires.txt>
systemd+kernel+grub2+grub2-efi+grubby+dracut+dnf (177 pkgs):
https://harald.fedorapeople.org/pkgset/f24-systemd-kernel-dnf-requires.txt
For a visualization I created some graphs for the systemd only dependencies:
<https://harald.fedorapeople.org/pkgset/systemd-all.svg>
and a reduced graph, which only displays one dep:
<https://harald.fedorapeople.org/pkgset/systemd.svg>
A couple of strange deps:
- libsemanage requires python
(filed as <https://bugzilla.redhat.com/show_bug.cgi?id=1248002>)
- emacs-filesystem - do we really need that?
- info - do we really require that for every package, that ships info pages?
- krb5-libs requires gawk - why do libs require utils other than ldconfig?
- same with device-mapper-libs requiring device-mapper
- chkconfig - really?
please add your findings and/or file bugs
9:09 a.m.
On Wed, Jul 29, 2015 at 03:42:28PM +0200, Harald Hoyer wrote:
In order to define the Base WG core package group and minimize
minimal
installations for e.g. cloud images and the atomic spin, I created some
dependency lists:
There are so many definitions of minimum sets:
systemd: container boot
systemd + bash + login: container boot with login
systemd + kernel + bootloader + dracut: machine boot
systemd + ... + sshd + firewalld: network minimal
Here is a little script to generate the filelist (which apparently is extended
by dnf and kickstart with other default packages):
<https://harald.fedorapeople.org/pkgset/pkgset.sh>
So, if we start with systemd, then we'll get 112 packages at least for rawhide.
systemd (112 pkgs):
<https://harald.fedorapeople.org/pkgset/f24-systemd-requires.txt>
systemd+kernel+grub2+grub2-efi+grubby+dracut (142 pkgs):
<https://harald.fedorapeople.org/pkgset/f24-systemd-kernel-requires.txt>
systemd+kernel+grub2+grub2-efi+grubby+dracut+dnf (177 pkgs):
https://harald.fedorapeople.org/pkgset/f24-systemd-kernel-dnf-requires.txt
For a visualization I created some graphs for the systemd only dependencies:
<https://harald.fedorapeople.org/pkgset/systemd-all.svg>
and a reduced graph, which only displays one dep:
<https://harald.fedorapeople.org/pkgset/systemd.svg>
A couple of strange deps:
- libsemanage requires python
(filed as <https://bugzilla.redhat.com/show_bug.cgi?id=1248002>)
- emacs-filesystem - do we really need that?
That's a package with three
directories... Guidelines require this dependency.
- info - do we really require that for every package, that ships info
pages?
This could be converted to a scheme where info (install-info precisely
speaking)
is not required, and is only called if it is present. And the info package
would have to install all pre-exisiting info pages upon installation.
(Something like this is done with gtk-update-icon-cache [1].)
info.rpm is rather small, so I doubt that this is worth the effort.
[1] https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache
- krb5-libs requires gawk - why do libs require utils other than
ldconfig?
- same with device-mapper-libs requiring device-mapper
- chkconfig - really?
As long as systemd supports sysvinit scripts, this will be
required.
Zbyszek
11:24 a.m.
On Wed, 29 Jul 2015 14:09:02 +0000, Zbigniew Jędrzejewski-Szmek wrote:
> A couple of strange deps:
> - emacs-filesystem - do we really need that?
That's a package with three directories... Guidelines require this dependency.
That's https://fedoraproject.org/wiki/Packaging:Emacs#Case_II_3
Dependency bloat only to get directory ownership right.
Some -filesystem packages contain shared libs. Others are not .noarch:
boost-filesystem.i686 1.57.0-6.fc22
fedora
boost-filesystem.x86_64 1.57.0-6.fc22
fedora
cinnamon-control-center-filesystem.i686 2.6.0-3.fc22
updates
cinnamon-control-center-filesystem.x86_64 2.6.0-3.fc22
updates
clamav-filesystem.noarch 0.98.7-1.fc22
fedora
eclipse-filesystem.x86_64 1.0-3.fc22
fedora
firebird-filesystem.x86_64 2.5.4.26856.0-1.fc22
fedora
gnustep-filesystem.x86_64 2.6.7-1.fc22
updates
ipsilon-filesystem.noarch 1.0.0-1.fc22
updates
kde-filesystem.x86_64 4-51.fc22
fedora
keyrings-filesystem.noarch 1-3.fc21
fedora
kf5-filesystem.noarch 5.9.0-1.fc22
fedora
kf5-filesystem.x86_64 5.12.0-1.fc22
updates-testing
libreport-filesystem.x86_64 2.6.2-1.fc22
updates-testing
lua-filesystem.x86_64 1.6.3-1.fc22
fedora
mate-control-center-filesystem.i686 1.10.1-1.fc22
updates
mate-control-center-filesystem.x86_64 1.10.1-1.fc22
updates
mesa-filesystem.i686 10.6.1-1.20150629.fc22
updates
mingw32-filesystem.noarch 100-1.fc22
fedora
mingw64-filesystem.noarch 100-1.fc22
fedora
nginx-filesystem.noarch 1:1.8.0-10.fc22
updates
nodoka-filesystem.noarch 0.3.90-10.fc21
fedora
npapi-vlc-filesystem.x86_64 2.2.0-0.1.fc22
rpmfusion-free
opencl-filesystem.noarch 1.0-2.fc21
fedora
pacman-filesystem.noarch 4.1.2-4.20130626git28cb22e.fc22
fedora
php-symfony-filesystem.noarch 2.5.12-1.fc22
updates
sigrok-firmware-filesystem.noarch 0.1.0-5.20130426git83e0802.fc21
fedora
vim-filesystem.x86_64 2:7.4.640-4.fc22
fedora
web-assets-filesystem.noarch 5-2.fc21
fedora
wine-filesystem.noarch 1.7.47-1.fc22
updates
yast2-filesystem.x86_64 0.1.0-1.fc22
fedora
12:56 p.m.
On Wed, 2015-07-29 at 18:24 +0200, Michael Schwendt wrote:
Some -filesystem packages contain shared libs. Others are not >
.noarch:
Not being noarch isn't a sin, mesa-filesystem owns %{_libdir}/dri so it
really can't be archful.
Also, boost-filesystem and lua-filesystem appear to just be confusingly
named, they really do contain a filesystem interface library.
- ajax
3:21 p.m.
On Wed, 29 Jul 2015 13:56:30 -0400, Adam Jackson wrote:
On Wed, 2015-07-29 at 18:24 +0200, Michael Schwendt wrote:
> Some -filesystem packages contain shared libs. Others are not > .noarch:
Not being noarch isn't a sin, mesa-filesystem owns %{_libdir}/dri so it
really can't be archful.
True. I didn't claim mesa-filesystem would be a mistake. At least no
packages "Requires: mesa-filesystem" without %_isa. That's good.
Arch-specific -filesystem packages are another hurdle for new packagers,
though. The guidelines don't give any hint/warning.
Also, boost-filesystem and lua-filesystem appear to just be
confusingly
named, they really do contain a filesystem interface library.
And I guess there are -common packages that contain a directory tree
and predate the -filesystem subpackage guidelines.
11:24 a.m.
On Wed, Jul 29, 2015 at 02:09:02PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> A couple of strange deps:
> - libsemanage requires python
> (filed as <https://bugzilla.redhat.com/show_bug.cgi?id=1248002>)
> - emacs-filesystem - do we really need that?
That's a package with three directories... Guidelines require this dependency.
It's pretty painless in itself, but then requires anyone to build emacs
itself as part of this, even if the main package isn't used. Maybe
those three directories should just be moved to the main filesystem
package?
But actually, what's bringing it in here? On my f22 system (which is
all I've got handy at this movement), it's required by autoconf, cmake,
desktop-file-utils, and rpmdevtools — none of which make Harald's list.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
11:29 a.m.
On Wed, 29 Jul 2015 12:24:17 -0400, Matthew Miller wrote:
On Wed, Jul 29, 2015 at 02:09:02PM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> > A couple of strange deps:
> > - libsemanage requires python
> > (filed as <https://bugzilla.redhat.com/show_bug.cgi?id=1248002>)
> > - emacs-filesystem - do we really need that?
> That's a package with three directories... Guidelines require this dependency.
It's pretty painless in itself, but then requires anyone to build emacs
itself as part of this, even if the main package isn't used. Maybe
those three directories should just be moved to the main filesystem
package?
But actually, what's bringing it in here? On my f22 system (which is
all I've got handy at this movement), it's required by autoconf, cmake,
desktop-file-utils, and rpmdevtools — none of which make Harald's list.
libidn
11:53 a.m.
On 29.07.2015 18:29, Michael Schwendt wrote:
On Wed, 29 Jul 2015 12:24:17 -0400, Matthew Miller wrote:
> On Wed, Jul 29, 2015 at 02:09:02PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
>>> A couple of strange deps:
>>> - libsemanage requires python
>>> (filed as <https://bugzilla.redhat.com/show_bug.cgi?id=1248002>)
>>> - emacs-filesystem - do we really need that?
>> That's a package with three directories... Guidelines require this
dependency.
>
> It's pretty painless in itself, but then requires anyone to build emacs
> itself as part of this, even if the main package isn't used. Maybe
> those three directories should just be moved to the main filesystem
> package?
>
> But actually, what's bringing it in here? On my f22 system (which is
> all I've got handy at this movement), it's required by autoconf, cmake,
> desktop-file-utils, and rpmdevtools — none of which make Harald's list.
libidn
# emacs-libidn merged with main package in 1.30-4
Obsoletes: emacs-libidn < 1.30-4
Provides: emacs-libidn < 1.30-4
Requires: emacs-filesystem >= %{_emacs_version}
Too bad it was merged :-/
* Thu Jun 25 2015 Miroslav Lichvar <mlichvar(a)redhat.com> - 1.30-4
- merge emacs-libidn with main package (#1234563)
"Package should not ship a separate emacs sub-package"
https://bugzilla.redhat.com/show_bug.cgi?id=1234563
"The Emacs add-on packaging guidelines no longer stipulate that packages which
also bundle support for Emacs should split out those Emacs files into separate
sub-packages. This package should instead ship those files with the main
package which should also Require emacs-filesystem. See
https://fedoraproject.org/wiki/Packaging:Emacs for more detail."
12:42 p.m.
New subject: Emacs packaging guidelines (was: Re: Fedora minimal installations)
On Wed, 29 Jul 2015 18:53:27 +0200, Harald Hoyer wrote:
"The Emacs add-on packaging guidelines no longer stipulate that
packages which
also bundle support for Emacs should split out those Emacs files into separate
sub-packages. This package should instead ship those files with the main
package which should also Require emacs-filesystem. See
https://fedoraproject.org/wiki/Packaging:Emacs for more detail."
And once again the wording is weak. It says "should". Three times even.
Based on that, calling existing emacs- subpackages "violations" is a
highly questionable thing to do. And new packagers would prefer more
clear and concise wording, too.
2:03 p.m.
New subject: Emacs packaging guidelines (was: Re: Fedora minimal installations)
On 29 July 2015 at 18:42, Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Wed, 29 Jul 2015 18:53:27 +0200, Harald Hoyer wrote:
> "The Emacs add-on packaging guidelines no longer stipulate that packages which
> also bundle support for Emacs should split out those Emacs files into separate
> sub-packages. This package should instead ship those files with the main
> package which should also Require emacs-filesystem. See
> https://fedoraproject.org/wiki/Packaging:Emacs for more detail."
And once again the wording is weak. It says "should". Three times even.
What's wrong with the word "should"? What am I missing? Seems like the
usual use of this word to me?
Based on that, calling existing emacs- subpackages
"violations" is a
highly questionable thing to do.
the only place the word "violation" appears is in an alias I gave to a
tracking bug I set up to track emacs packages which haven't update to
the new guidelines. It doesn't appear in the bug report.
And new packagers would prefer more
clear and concise wording, too.
It'd be great if you could suggest a clearer wording - the current
guidelines resulted from an effort to clarify the old ones, but I'm
sure there's room for improvement. I'd happily read over a draft if
you prepared one for the FPC, I definitely agree the current ones are
a bit cumbersome.
Cheers,
Jonathan.
2:08 p.m.
New subject: Emacs packaging guidelines (was: Re: Fedora minimal installations)
On Wed, Jul 29, 2015 at 08:03:00PM +0100, Jonathan Underwood wrote:
>> "The Emacs add-on packaging guidelines no longer
stipulate that packages which
>> also bundle support for Emacs should split out those Emacs files into separate
>> sub-packages. This package should instead ship those files with the main
>> package which should also Require emacs-filesystem. See
>> https://fedoraproject.org/wiki/Packaging:Emacs for more detail."
> And once again the wording is weak. It says "should". Three times even.
What's wrong with the word "should"? What am I missing? Seems like the
usual use of this word to me?
Presuambly this: https://www.ietf.org/rfc/rfc2119.txt
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:12 p.m.
New subject: Emacs packaging guidelines (was: Re: Fedora minimal installations)
On 29 July 2015 at 20:08, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Wed, Jul 29, 2015 at 08:03:00PM +0100, Jonathan Underwood wrote:
> >> "The Emacs add-on packaging guidelines no longer stipulate that
packages which
> >> also bundle support for Emacs should split out those Emacs files into
separate
> >> sub-packages. This package should instead ship those files with the main
> >> package which should also Require emacs-filesystem. See
> >> https://fedoraproject.org/wiki/Packaging:Emacs for more detail."
> > And once again the wording is weak. It says "should". Three times
even.
> What's wrong with the word "should"? What am I missing? Seems like the
> usual use of this word to me?
Presuambly this: https://www.ietf.org/rfc/rfc2119.txt
OK, so that's exactly what I intended when I wrote the text of the bug
report (I had that definition in mind) - I thought there might be
unforseen valid reasons not to merge the emacs- subpackage into the
main package, and hence didn't use "must". So, I am still not seeing
my error here but I would like to, so I can avoid it in future...
3:04 p.m.
New subject: Emacs packaging guidelines (was: Re: Fedora minimal installations)
On Wed, 29 Jul 2015 20:12:56 +0100, Jonathan Underwood wrote:
>> >> https://fedoraproject.org/wiki/Packaging:Emacs for
more detail."
>> > And once again the wording is weak. It says "should". Three times
even.
>> What's wrong with the word "should"? What am I missing? Seems like
the
>> usual use of this word to me?
>
> Presuambly this: https://www.ietf.org/rfc/rfc2119.txt
Sort of.
OK, so that's exactly what I intended when I wrote the text of
the bug
report (I had that definition in mind) - I thought there might be
unforseen valid reasons not to merge the emacs- subpackage into the
main package, and hence didn't use "must". So, I am still not seeing
my error here but I would like to, so I can avoid it in future...
I am not a native speaker of English, but indeed there are stronger
forms, such as "ought to", "must" and "have to". The latter
two are
more clear about whether the packager is permitted to create an emacs-
subpackage as a matter of freedom. On the contrary, "should" implies
freedom, i.e. the packager "need not" ship Emacs Lisp files in the
base package and "need not" add a dependency on emacs-filesystem,
but may create an emacs- subpackage instead.
It's the same with the "multiple directory ownership" guidelines, which
don't mandate that packager _must_ require -filesystem packages, if
available. They say "should" and people read it as a recommendation
instead of a strict rule/policy.
When dealing with [new] packagers in the review queue, ambiguous wording
can be a pain.
3:18 a.m.
New subject: Emacs packaging guidelines
Dne 29.7.2015 v 19:42 Michael Schwendt napsal(a):
On Wed, 29 Jul 2015 18:53:27 +0200, Harald Hoyer wrote:
> "The Emacs add-on packaging guidelines no longer stipulate that packages which
> also bundle support for Emacs should split out those Emacs files into separate
> sub-packages. This package should instead ship those files with the main
> package which should also Require emacs-filesystem. See
> https://fedoraproject.org/wiki/Packaging:Emacs for more detail."
And once again the wording is weak. It says "should". Three times even.
Based on that, calling existing emacs- subpackages "violations" is a
highly questionable thing to do. And new packagers would prefer more
clear and concise wording, too.
Actually what is the point of following?
```
Case II
Where a package's principal functionality does not require (X)Emacs, but
the package also includes some auxiliary Elisp files to provide support
for the package in (X)Emacs, these should be included in the main
package which will need to Require the emacs-filesystem and/or
xemacs-filesystem packages. More detail below.
```
Why the files should be provided in the main package? Why it should not
be subpackage? It is exaclty against principles applied anywhere else,
e.g. if I have library with binding for some language, these binding
will be probably in corresponding -language subpackage.
Vít
5:27 a.m.
New subject: Emacs packaging guidelines
On Thu, 30 Jul 2015 10:18:13 +0200, Vít Ondruch wrote:
Actually what is the point of following?
```
Case II
Where a package's principal functionality does not require (X)Emacs, but
the package also includes some auxiliary Elisp files to provide support
for the package in (X)Emacs, these should be included in the main
package which will need to Require the emacs-filesystem and/or
xemacs-filesystem packages. More detail below.
```
Why the files should be provided in the main package? Why it should not
be subpackage?
There's some background at the bottom of the page:
https://fedoraproject.org/wiki/Packaging:Emacs#Other_packages_containing_...
| It is often the case that a software package, while not being
| primarily an Emacs add-on package, will contain components for
| (X)Emacs. For example, the Gnuplot program contains some elisp files
| for editing Gnuplot input files in GNU Emacs and running Gnuplot
| from GNU Emacs. In this case, we want to enable the (X)Emacs support
| IF (X)Emacs is installed, but we don't want to mandate the
| installation of (X)Emacs on installation of this package since
| (X)Emacs is not required for providing the core functionality of the
| package. To enable this, the emacs-filesystem and xemacs-filesystem
| sub-packages were created which own the /usr/share/emacs/site-lisp
| and /usr/share/xmeacs/site-packages directories respectively. A
| package can then Require these (x)emacsfilesystem packages in order
| to install their Elisp files without pulling in (X)Emacs and their
| dependency chain.
It's like saying "we don't care much about those files, we just don't
want to delete them, so we include them to make them available somewhere
for those people who manage to find them, and btw, Emacs/XEmacs users
may want to look at using Emacs' own package management anyway since
it won't be possible to package all available extensions".
Reminds me of:
$ dnf list texlive\*|wc -l
5262
It is exaclty against principles applied anywhere else,
e.g. if I have library with binding for some language, these binding
will be probably in corresponding -language subpackage.
True. It seems to be an arbitrary decision to not follow the general
%{parent}-%{child} naming guidelines for add-on packages. It's hiding add-ons
within the base package, which obviously cannot follow the naming guidelines,
if it's not only an add-on to X/Emacs. Still that's hiding the add-ons from
the emacs-foo namespace unless the "Provides" is kept forever.
5:39 a.m.
New subject: Emacs packaging guidelines
On 30 July 2015 at 11:27, Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Thu, 30 Jul 2015 10:18:13 +0200, Vít Ondruch wrote:
> Actually what is the point of following?
>
> ```
> Case II
>
> Where a package's principal functionality does not require (X)Emacs, but
> the package also includes some auxiliary Elisp files to provide support
> for the package in (X)Emacs, these should be included in the main
> package which will need to Require the emacs-filesystem and/or
> xemacs-filesystem packages. More detail below.
> ```
>
> Why the files should be provided in the main package? Why it should not
> be subpackage?
There's some background at the bottom of the page:
https://fedoraproject.org/wiki/Packaging:Emacs#Other_packages_containing_...
| It is often the case that a software package, while not being
| primarily an Emacs add-on package, will contain components for
| (X)Emacs. For example, the Gnuplot program contains some elisp files
| for editing Gnuplot input files in GNU Emacs and running Gnuplot
| from GNU Emacs. In this case, we want to enable the (X)Emacs support
| IF (X)Emacs is installed, but we don't want to mandate the
| installation of (X)Emacs on installation of this package since
| (X)Emacs is not required for providing the core functionality of the
| package. To enable this, the emacs-filesystem and xemacs-filesystem
| sub-packages were created which own the /usr/share/emacs/site-lisp
| and /usr/share/xmeacs/site-packages directories respectively. A
| package can then Require these (x)emacsfilesystem packages in order
| to install their Elisp files without pulling in (X)Emacs and their
| dependency chain.
It's like saying "we don't care much about those files, we just don't
want to delete them, so we include them to make them available somewhere
for those people who manage to find them, and btw, Emacs/XEmacs users
may want to look at using Emacs' own package management anyway since
it won't be possible to package all available extensions".
Yes, that's part of the story. The current guidelines were put in
place at Fedora 16. Prior to that, the guidelines stipulated that the
emacs bits were split off into an emacs-foo sub-package, as Vit
suggests (and I would agree) is more compliant with other packaging
practices. However, many packagers ignored that and just included the
emacs files in the main package without any kind of emacs dependency,
no byte compilation etc, and most reviewers didn't pick up on this
during package review. It was also argued that splitting out one or
two files into a sub-package bloated the package set and associated
metadata. So, the current guideline was an attempt to be a bit more
pragmatic about the situation, and have the nice effect that a user
who installs emacs automagically has all these bits working without
having to manually do a bunch of dnf install emacs-blah packages. So,
that's how we got to here. If there's a general consensus that we want
to switch back to the splitting out of emacs sub-packages, I would
definitely support that initiative. But I think (and I'm not speaking
for them) the FPC would want to see good reasons for flip-flopping the
guidelines again.
Reminds me of:
$ dnf list texlive\*|wc -l
5262
> It is exaclty against principles applied anywhere else,
> e.g. if I have library with binding for some language, these binding
> will be probably in corresponding -language subpackage.
True. It seems to be an arbitrary decision to not follow the general
%{parent}-%{child} naming guidelines for add-on packages. It's hiding add-ons
within the base package, which obviously cannot follow the naming guidelines,
if it's not only an add-on to X/Emacs. Still that's hiding the add-ons from
the emacs-foo namespace unless the "Provides" is kept forever.
That's right. Happens also for vim scripts etc as well.
Jonathan.
5:48 a.m.
New subject: Emacs packaging guidelines
Dne 30.7.2015 v 12:39 Jonathan Underwood napsal(a):
On 30 July 2015 at 11:27, Michael Schwendt
<mschwendt(a)gmail.com> wrote:
> On Thu, 30 Jul 2015 10:18:13 +0200, Vít Ondruch wrote:
>
>> Actually what is the point of following?
>>
>> ```
>> Case II
>>
>> Where a package's principal functionality does not require (X)Emacs, but
>> the package also includes some auxiliary Elisp files to provide support
>> for the package in (X)Emacs, these should be included in the main
>> package which will need to Require the emacs-filesystem and/or
>> xemacs-filesystem packages. More detail below.
>> ```
>>
>> Why the files should be provided in the main package? Why it should not
>> be subpackage?
> There's some background at the bottom of the page:
>
>
https://fedoraproject.org/wiki/Packaging:Emacs#Other_packages_containing_...
>
> | It is often the case that a software package, while not being
> | primarily an Emacs add-on package, will contain components for
> | (X)Emacs. For example, the Gnuplot program contains some elisp files
> | for editing Gnuplot input files in GNU Emacs and running Gnuplot
> | from GNU Emacs. In this case, we want to enable the (X)Emacs support
> | IF (X)Emacs is installed, but we don't want to mandate the
> | installation of (X)Emacs on installation of this package since
> | (X)Emacs is not required for providing the core functionality of the
> | package. To enable this, the emacs-filesystem and xemacs-filesystem
> | sub-packages were created which own the /usr/share/emacs/site-lisp
> | and /usr/share/xmeacs/site-packages directories respectively. A
> | package can then Require these (x)emacsfilesystem packages in order
> | to install their Elisp files without pulling in (X)Emacs and their
> | dependency chain.
>
> It's like saying "we don't care much about those files, we just
don't
> want to delete them, so we include them to make them available somewhere
> for those people who manage to find them, and btw, Emacs/XEmacs users
> may want to look at using Emacs' own package management anyway since
> it won't be possible to package all available extensions".
Yes, that's part of the story. The current guidelines were put in
place at Fedora 16. Prior to that, the guidelines stipulated that the
emacs bits were split off into an emacs-foo sub-package, as Vit
suggests (and I would agree) is more compliant with other packaging
practices. However, many packagers ignored that and just included the
emacs files in the main package without any kind of emacs dependency,
no byte compilation etc, and most reviewers didn't pick up on this
during package review. It was also argued that splitting out one or
two files into a sub-package bloated the package set and associated
metadata. So, the current guideline was an attempt to be a bit more
pragmatic about the situation, and have the nice effect that a user
who installs emacs automagically has all these bits working without
having to manually do a bunch of dnf install emacs-blah packages. So,
that's how we got to here. If there's a general consensus that we want
to switch back to the splitting out of emacs sub-packages, I would
definitely support that initiative. But I think (and I'm not speaking
for them) the FPC would want to see good reasons for flip-flopping the
guidelines again.
These are definitely fair points, but at the end, this should be left up
to the maintainer if there will be -emacs package and the general
preference should be to support the subpackages. I hope it will give as
greater opportunities with incoming boolean dependencies, such as
"install the -emacs subpackage when emacs is already installed".
Vít
6:02 a.m.
New subject: Emacs packaging guidelines
On 30 July 2015 at 11:48, Vít Ondruch <vondruch(a)redhat.com> wrote:
[snip]
These are definitely fair points, but at the end, this should be left
up
to the maintainer if there will be -emacs package and the general
preference should be to support the subpackages. I hope it will give as
greater opportunities with incoming boolean dependencies, such as
"install the -emacs subpackage when emacs is already installed".
Perhaps so - I encourage you to prepare a new draft of the guidelines
to encapsulate how you'd like to see this work for the FPC to
consider. I'll happily read over anything you write, if you like, and
help where I can.
Cheers,
Jonathan
6:22 a.m.
New subject: Emacs packaging guidelines
On Thu, 30 Jul 2015 12:02:05 +0100, Jonathan Underwood wrote:
On 30 July 2015 at 11:48, Vít Ondruch wrote:
[snip]
> These are definitely fair points, but at the end, this should be left up
> to the maintainer if there will be -emacs package and the general
> preference should be to support the subpackages. I hope it will give as
> greater opportunities with incoming boolean dependencies, such as
> "install the -emacs subpackage when emacs is already installed".
>
Perhaps so - I encourage you to prepare a new draft of the guidelines
to encapsulate how you'd like to see this work for the FPC to
consider. I'll happily read over anything you write, if you like, and
help where I can.
The beauty of %{parent}-%{child} naming is that it is your only hope if you
want to browse what's available for Emacs,
dnf list emacs\* | less
or a similar search in other package tools. Especially if there are
hundreds or thousands of packages in that list. Else you need to know
exactly what to search for ==> a very limited target group (people pick
a very few packages and won't ever care about the other thousands ones,
since it's not feasible to become familiar with what's available).
$ dnf list \*-fonts|wc -l
667
*sigh* Searching for "font" gives a few hundred more results.
My stomach ;) would prefer reducing the number of packages in a namespace
to a dozen or at most 20 large ones to get "everything" in less pieces,
but when building from individual src.rpm packages, that would require
a completely different build-/packaging-system.
Off-topic, oh well. :-)
6:05 a.m.
New subject: Emacs packaging guidelines
On Thu, 30 Jul 2015 11:39:00 +0100, Jonathan Underwood wrote:
If there's a general consensus that we want
to switch back to the splitting out of emacs sub-packages, I would
definitely support that initiative. But I think (and I'm not speaking
for them) the FPC would want to see good reasons for flip-flopping the
guidelines again.
The current guidelines leave the decision to the packager. In cases
where the base package includes much more than an extension of Emacs,
you are free to create an emacs- subpackage, if you prefer that
packaging-style. There is no preference to do so, however.
I still don't see how existing emacs- subpackages "violate" the
guidelines. One may ask packagers to consider getting rid of some
tiny subpackages, but is it worthwhile?
$ dnf list emacs\*|wc -l
95
$ dnf list xemacs\*|wc -l
27
For less packages, for some time you gain dozens of Obsoletes/Provides
(as well as packagers keeping those for a very long time).
Eventually, an extension included in a base package will grow in size and
will be considered a problem again, raising the desire to split off those
files.
As much as I like a "minimal installation" as a base core for spins and
other products, I'm a much bigger fan of fewer and bigger packages instead
of confronting and overwhelming distribution users with thousands of packages.
You search the package collection and get a thousand [sub-]packages, you're lost.
6:30 a.m.
New subject: Emacs packaging guidelines
On Thu, 30 Jul 2015 13:05:13 +0200, Michael Schwendt wrote:
As much as I like a "minimal installation" as a base core
for spins and
other products, I'm a much bigger fan of fewer and bigger packages instead
of confronting and overwhelming distribution users with thousands of packages.
You search the package collection and get a thousand [sub-]packages, you're lost.
Important to point out:
This is not to be understood as an argument _against_ "emacs-" subpackages,
it's only my more general feeling with regard to packaging thousands
of individual tiny add-ons. Providing some extensions, okay. Trying to
provide thousands in thousands of packages, that's insane.
5:43 a.m.
New subject: Emacs packaging guidelines
Dne 30.7.2015 v 12:27 Michael Schwendt napsal(a):
On Thu, 30 Jul 2015 10:18:13 +0200, Vít Ondruch wrote:
> Actually what is the point of following?
>
> ```
> Case II
>
> Where a package's principal functionality does not require (X)Emacs, but
> the package also includes some auxiliary Elisp files to provide support
> for the package in (X)Emacs, these should be included in the main
> package which will need to Require the emacs-filesystem and/or
> xemacs-filesystem packages. More detail below.
> ```
>
> Why the files should be provided in the main package? Why it should not
> be subpackage?
There's some background at the bottom of the page:
https://fedoraproject.org/wiki/Packaging:Emacs#Other_packages_containing_...
| It is often the case that a software package, while not being
| primarily an Emacs add-on package, will contain components for
| (X)Emacs. For example, the Gnuplot program contains some elisp files
| for editing Gnuplot input files in GNU Emacs and running Gnuplot
| from GNU Emacs. In this case, we want to enable the (X)Emacs support
| IF (X)Emacs is installed, but we don't want to mandate the
| installation of (X)Emacs on installation of this package since
| (X)Emacs is not required for providing the core functionality of the
| package. To enable this, the emacs-filesystem and xemacs-filesystem
| sub-packages were created which own the /usr/share/emacs/site-lisp
| and /usr/share/xmeacs/site-packages directories respectively. A
| package can then Require these (x)emacsfilesystem packages in order
| to install their Elisp files without pulling in (X)Emacs and their
| dependency chain.
It's like saying "we don't care much about those files, we just don't
want to delete them, so we include them to make them available somewhere
for those people who manage to find them, and btw, Emacs/XEmacs users
may want to look at using Emacs' own package management anyway since
it won't be possible to package all available extensions".
I read that, but there is no really explained why it should not be
subpackage. Moreover, I am not sure if you support my point or you are
against :)
Vít
Reminds me of:
$ dnf list texlive\*|wc -l
5262
> It is exaclty against principles applied anywhere else,
> e.g. if I have library with binding for some language, these binding
> will be probably in corresponding -language subpackage.
True. It seems to be an arbitrary decision to not follow the general
%{parent}-%{child} naming guidelines for add-on packages. It's hiding add-ons
within the base package, which obviously cannot follow the naming guidelines,
if it's not only an add-on to X/Emacs. Still that's hiding the add-ons from
the emacs-foo namespace unless the "Provides" is kept forever.
6:25 a.m.
New subject: Emacs packaging guidelines
On Thu, 30 Jul 2015 12:43:15 +0200, Vít Ondruch wrote:
I read that, but there is no really explained why it should not be
subpackage. Moreover, I am not sure if you support my point or you are
against :)
https://lists.fedoraproject.org/pipermail/devel/2015-July/212924.html
1:53 p.m.
On 29 July 2015 at 17:29, Michael Schwendt <mschwendt(a)gmail.com> wrote:
On Wed, 29 Jul 2015 12:24:17 -0400, Matthew Miller wrote:
> On Wed, Jul 29, 2015 at 02:09:02PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > > A couple of strange deps:
> > > - libsemanage requires python
> > > (filed as <https://bugzilla.redhat.com/show_bug.cgi?id=1248002>)
> > > - emacs-filesystem - do we really need that?
> > That's a package with three directories... Guidelines require this
dependency.
>
> It's pretty painless in itself, but then requires anyone to build emacs
> itself as part of this, even if the main package isn't used. Maybe
> those three directories should just be moved to the main filesystem
> package?
>
> But actually, what's bringing it in here? On my f22 system (which is
> all I've got handy at this movement), it's required by autoconf, cmake,
> desktop-file-utils, and rpmdevtools — none of which make Harald's list.
libidn
This must be new - libidn isn't present on my F22 system, and systemd is.
2:05 p.m.
On 29 July 2015 at 17:24, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Wed, Jul 29, 2015 at 02:09:02PM +0000, Zbigniew Jędrzejewski-Szmek
wrote:
> > A couple of strange deps:
> > - libsemanage requires python
> > (filed as <https://bugzilla.redhat.com/show_bug.cgi?id=1248002>)
> > - emacs-filesystem - do we really need that?
> That's a package with three directories... Guidelines require this dependency.
It's pretty painless in itself, but then requires anyone to build emacs
itself as part of this, even if the main package isn't used. Maybe
those three directories should just be moved to the main filesystem
package?
That's probably the best fix (and add a Provides for emacs-filesystem
to the filesystem package at the same time).
3:14 p.m.
On Wed, 29 Jul 2015 20:05:52 +0100, Jonathan Underwood wrote:
>> > - emacs-filesystem - do we really need that?
>> That's a package with three directories... Guidelines require this
dependency.
>
> It's pretty painless in itself, but then requires anyone to build emacs
> itself as part of this, even if the main package isn't used. Maybe
> those three directories should just be moved to the main filesystem
> package?
That's probably the best fix (and add a Provides for emacs-filesystem
to the filesystem package at the same time).
Seriously?
Where to start? Where to stop?
$ rpmls filesystem|grep ^d|wc -l
15733
Today you add directories for Emacs, tomorrow you add directories
for even further packages that are in the same problem space?
Please!
Sometimes -filesystem subpackages contain versioned directories.
You cannot predict what will be necessary.
I can understand creating filesystem packages for directories
with very special ownership and permissions, but not the common
(755,root,root) case. It is not a big deal to include them in
multiple packages. And perhaps one day RPM will do something
about directory ownership on-the-fly, too.
4:13 p.m.
On Wed, Jul 29, 2015 at 10:14:05PM +0200, Michael Schwendt wrote:
> >> > - emacs-filesystem - do we really need that?
> >> That's a package with three directories... Guidelines require this
dependency.
> > It's pretty painless in itself, but then requires anyone to build emacs
> > itself as part of this, even if the main package isn't used. Maybe
> > those three directories should just be moved to the main filesystem
> > package?
> That's probably the best fix (and add a Provides for emacs-filesystem
> to the filesystem package at the same time).
Seriously?
Where to start? Where to stop?
Start? At packages that are in the minimal set as discussed here. Stop?
Somewhere above that. Pick a line.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
12:47 p.m.
On 29.07.2015 16:09, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jul 29, 2015 at 03:42:28PM +0200, Harald Hoyer wrote:
> In order to define the Base WG core package group and minimize minimal
> installations for e.g. cloud images and the atomic spin, I created some
> dependency lists:
>
> There are so many definitions of minimum sets:
>
> systemd: container boot
> systemd + bash + login: container boot with login
> systemd + kernel + bootloader + dracut: machine boot
> systemd + ... + sshd + firewalld: network minimal
>
> Here is a little script to generate the filelist (which apparently is extended
> by dnf and kickstart with other default packages):
> <https://harald.fedorapeople.org/pkgset/pkgset.sh>
>
> So, if we start with systemd, then we'll get 112 packages at least for rawhide.
> systemd (112 pkgs):
> <https://harald.fedorapeople.org/pkgset/f24-systemd-requires.txt>
>
> systemd+kernel+grub2+grub2-efi+grubby+dracut (142 pkgs):
> <https://harald.fedorapeople.org/pkgset/f24-systemd-kernel-requires.txt>
>
> systemd+kernel+grub2+grub2-efi+grubby+dracut+dnf (177 pkgs):
> https://harald.fedorapeople.org/pkgset/f24-systemd-kernel-dnf-requires.txt
>
>
> For a visualization I created some graphs for the systemd only dependencies:
>
> <https://harald.fedorapeople.org/pkgset/systemd-all.svg>
>
> and a reduced graph, which only displays one dep:
>
> <https://harald.fedorapeople.org/pkgset/systemd.svg>
>
>
> A couple of strange deps:
> - libsemanage requires python
> (filed as <https://bugzilla.redhat.com/show_bug.cgi?id=1248002>)
> - emacs-filesystem - do we really need that?
That's a package with three directories... Guidelines require this dependency.
> - info - do we really require that for every package, that ships info pages?
This could be converted to a scheme where info (install-info precisely speaking)
is not required, and is only called if it is present. And the info package
would have to install all pre-exisiting info pages upon installation.
(Something like this is done with gtk-update-icon-cache [1].)
info.rpm is rather small, so I doubt that this is worth the effort.
[1] https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache
and with %transfiletriggerin this could even be automated from within the info
package. <http://rpm.org/wiki/FileTriggers>
%transfiletriggerin -- %{_infodir}
while read -r file || [ -n "$line" ]; do
/sbin/install-info "$file" %{_infodir}/dir || :
done
%transfiletriggerpostun -- %{_infodir}
while read -r file || [ -n "$line" ]; do
/sbin/install-info --delete "$file" %{_infodir}/dir || :
done
And we could just drop all the %post and %preun from the other zillion spec files.
1:33 p.m.
On Wed, 2015-07-29 at 15:42 +0200, Harald Hoyer wrote:
- krb5-libs requires gawk - why do libs require utils other than
ldconfig?
This looks like it was originally a Requires(triggerun) for the
configure_default_ccache_name case. Since that's handling upgrading
from <= 1.11.3-16, we can probably drop it now:
dmt:~% (echo f19; echo f20) | xargs -n1 -I@ koji -q latest-pkg @ krb5
krb5-1.11.3-1.fc19 f19 nalin
krb5-1.11.3-33.fc20 f20 nalin
- same with device-mapper-libs requiring device-mapper
* Wed Jun 23 2010 Alasdair Kergon <agk(a)redhat.com> - 2.02.68-1
- Have device-mapper-libs require device-mapper (circular) for udev rules.
Which is somewhat legitimate, since some of those rules do look like
they require calling out to tools provided in the base package:
ENV{DM_COOKIE}=="?*", IMPORT{program}="/usr/sbin/dmsetup udevflags
$env{DM_COOKIE}"
From staring at the reduced graph a bit, openldap -> nss-tools,
which
is the only thing pulling in the NSS stack. This looks pretty bogus to
me, openldap is just the core library package and none of them seem to
have any exec calls to anything in nss-tools.
- ajax
1:40 p.m.
On Wed, Jul 29, 2015 at 02:33:22PM -0400, Adam Jackson wrote:
From staring at the reduced graph a bit, openldap -> nss-tools,
which
is the only thing pulling in the NSS stack. This looks pretty bogus to
me, openldap is just the core library package and none of them seem to
have any exec calls to anything in nss-tools.
Oooh. That'd be a big win. Only one crypto library in the minimal
install?!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1:51 p.m.
On Wed, 2015-07-29 at 14:40 -0400, Matthew Miller wrote:
On Wed, Jul 29, 2015 at 02:33:22PM -0400, Adam Jackson wrote:
> From staring at the reduced graph a bit, openldap -> nss-tools,
> which
> is the only thing pulling in the NSS stack. This looks pretty
> bogus to
> me, openldap is just the core library package and none of them seem
> to
> have any exec calls to anything in nss-tools.
Oooh. That'd be a big win. Only one crypto library in the minimal
install?!
Last I heard, OpenLDAP was looking to drop its requirement on NSS
entirely, due to it not being well-supported upstream. (It was added
for FIPS support, but now OpenSSL has that).
2 p.m.
On Wed, 2015-07-29 at 14:40 -0400, Matthew Miller wrote:
On Wed, Jul 29, 2015 at 02:33:22PM -0400, Adam Jackson wrote:
> From staring at the reduced graph a bit, openldap -> nss-tools, which
> is the only thing pulling in the NSS stack. This looks pretty bogus to
> me, openldap is just the core library package and none of them seem to
> have any exec calls to anything in nss-tools.
Oooh. That'd be a big win. Only one crypto library in the minimal
install?!
Two, openssl and libgcrypt. But yeah, would still be about 6M gone from
the "what systemd pulls in" footprint.
Relatedly, nss-softokn -> sqlite -> readline, but the readline part is
just for /usr/bin/sqlite3, not for the library which is all nss-softokn
needs. So that could be split, too.
- ajax
2:17 p.m.
Am 29.07.2015 20:33 schrieb "Adam Jackson" <ajax(a)redhat.com>:
On Wed, 2015-07-29 at 15:42 +0200, Harald Hoyer wrote:
> - krb5-libs requires gawk - why do libs require utils other than
> ldconfig?
This looks like it was originally a Requires(triggerun) for the
configure_default_ccache_name case. Since that's handling upgrading
from <= 1.11.3-16, we can probably drop it now:
dmt:~% (echo f19; echo f20) | xargs -n1 -I@ koji -q latest-pkg @ krb5
krb5-1.11.3-1.fc19 f19 nalin
krb5-1.11.3-33.fc20 f20 nalin
> - same with device-mapper-libs requiring device-mapper
* Wed Jun 23 2010 Alasdair Kergon <agk(a)redhat.com> - 2.02.68-1
- Have device-mapper-libs require device-mapper (circular) for udev rules.
Which is somewhat legitimate, since some of those rules do look like
they require calling out to tools provided in the base package:
ENV{DM_COOKIE}=="?*", IMPORT{program}="/usr/sbin/dmsetup udevflags
$env{DM_COOKIE}"
Well, then why not ship the udev rules with device-mapper instead of the
libs?
From staring at the reduced graph a bit, openldap -> nss-tools, which
is the only thing pulling in the NSS stack. This looks pretty bogus to
me, openldap is just the core library package and none of them seem to
have any exec calls to anything in nss-tools.
- ajax
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
2:48 p.m.
Am 29.07.2015 21:44 schrieb "Adam Jackson" <ajax(a)redhat.com>:
On Wed, 2015-07-29 at 21:17 +0200, Harald Hoyer wrote:
>
> Well, then why not ship the udev rules with device-mapper instead of
> the libs?
I don't understand the question. They _are_ shipped in device-mapper.
Then I don't get the argument of the libs requiring device-mapper. /me is
puzzled.
3:19 p.m.
On Wed, Jul 29, 2015 at 09:48:49PM +0200, Harald Hoyer wrote:
Am 29.07.2015 21:44 schrieb "Adam Jackson"
<ajax(a)redhat.com>:
>
> On Wed, 2015-07-29 at 21:17 +0200, Harald Hoyer wrote:
> >
> > Well, then why not ship the udev rules with device-mapper instead of
> > the libs?
>
> I don't understand the question. They _are_ shipped in device-mapper.
>
Then I don't get the argument of the libs requiring device-mapper. /me is
puzzled.
Looks like a mistake.
https://bugzilla.redhat.com/show_bug.cgi?id=1248200 filed.
Zbyszek
4:25 p.m.
On Wed, 2015-07-29 at 21:48 +0200, Harald Hoyer wrote:
Then I don't get the argument of the libs requiring
device-mapper.
/me is puzzled.
The changelog message sort of implies the libs contain code that
doesn't work unless the rules have run. So the rules have to be
installed, but they call out to binaries that are in the main package,
so they won't _work_ unless the main package is installed...
In other words, the split between the packages is somewhat arbitrary,
and the code probably would need to be fixed to be less insane.
- ajax
6:20 p.m.
Am 29.07.2015 23:26 schrieb "Adam Jackson" <ajax(a)redhat.com>:
On Wed, 2015-07-29 at 21:48 +0200, Harald Hoyer wrote:
> Then I don't get the argument of the libs requiring device-mapper.
> /me is puzzled.
The changelog message sort of implies the libs contain code that
doesn't work unless the rules have run. So the rules have to be
installed, but they call out to binaries that are in the main package,
so they won't _work_ unless the main package is installed...
In other words, the split between the packages is somewhat arbitrary,
and the code probably would need to be fixed to be less insane.
Totally agreed 👍
3203
days inactive
3204
days old
37 comments
9 participants
participants (9)
-
Adam Jackson -
Harald Hoyer -
Harald Hoyer -
Jonathan Underwood -
Matthew Miller -
Michael Schwendt -
Stephen Gallagher -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek