Hi,
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
Thanks,
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1133786 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123813
On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
Hi,
Hi Vít,
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
At some point in time (F16 IIRC) we had systemd-units package which contained /etc/rpm/macros.systemd file. Packagers which followed our guidelines used for example %{unitdir} macro in %files. Hence they added systemd-units to BuildRequires.
These days systemd-units no longer exists, macro file moved to systemd rpm and systemd-units is a provided by systemd rpm. Therefore systemd proper creeping into buildroots.
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
Thanks,
Vít
Michal
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1133786 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123813 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Dne 26.8.2014 11:06, Michal Sekletar napsal(a):
On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
Hi,
Hi Vít,
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
At some point in time (F16 IIRC) we had systemd-units package which contained /etc/rpm/macros.systemd file. Packagers which followed our guidelines used for example %{unitdir} macro in %files. Hence they added systemd-units to BuildRequires.
These days systemd-units no longer exists, macro file moved to systemd rpm and systemd-units is a provided by systemd rpm.
Thank you for insightful explanation.
Nevertheless, if you are using some macro, it is just build time dependency. I believe that the issue might be due to %{unitdir} folder ownership. And I see two solutions:
1) Packages which ships unit files should consider to put them into sub package called either -daemon or -server. And this applies especially to packages such as man (forgot to mention this one previously), rsync or subversion. I don't typically use their server features or con jobs or whatever.
2) sytemd should consider to provide -filesystem package, which would limit the dependency to single small package (but this might be return to the -units subpackage days? Not sure).
Their combination might be the best solution.
Vít
On Tue, Aug 26, 2014 at 12:59:23PM +0200, Vít Ondruch wrote:
Dne 26.8.2014 11:06, Michal Sekletar napsal(a):
On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
Hi,
Hi Vít,
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
At some point in time (F16 IIRC) we had systemd-units package which contained /etc/rpm/macros.systemd file. Packagers which followed our guidelines used for example %{unitdir} macro in %files. Hence they added systemd-units to BuildRequires.
These days systemd-units no longer exists, macro file moved to systemd rpm and systemd-units is a provided by systemd rpm.
Thank you for insightful explanation.
Nevertheless, if you are using some macro, it is just build time dependency. I believe that the issue might be due to %{unitdir} folder ownership. And I see two solutions:
Yes it is build time dependency only.
- Packages which ships unit files should consider to put them into sub
package called either -daemon or -server. And this applies especially to packages such as man (forgot to mention this one previously), rsync or subversion. I don't typically use their server features or con jobs or whatever.
I think we can't make this a general rule. There are packages which has to ship unit files in a main package and I'd argue that we have quite a lot of those. Note that it is rather gut feeling not a fact I researched or measured in any way. In any case having *recomendation* in guidelines doesn't hurt, thus such split should be left at the curtesy of the individual maintainers.
But then again, I am not against such change in packages where it makes sense.
- sytemd should consider to provide -filesystem package, which would
limit the dependency to single small package (but this might be return to the -units subpackage days? Not sure).
That may improve a situation, but we have to commit to not going down the same road in the future as we did with systemd-units. However I don't have all the context why systemd-units was merged into systemd back then.
Their combination might be the best solution.
Vít
Michal
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Tue, 26.08.14 12:59, Vít Ondruch (vondruch@redhat.com) wrote:
- sytemd should consider to provide -filesystem package, which would
limit the dependency to single small package (but this might be return to the -units subpackage days? Not sure).
Why?
I am really against splitting things up into a million of subpackages, unless you have a ver good reason for a split.
Lennart
Dne 26.8.2014 13:51, Lennart Poettering napsal(a):
On Tue, 26.08.14 12:59, Vít Ondruch (vondruch@redhat.com) wrote:
- sytemd should consider to provide -filesystem package, which would
limit the dependency to single small package (but this might be return to the -units subpackage days? Not sure).
Why?
I am really against splitting things up into a million of subpackages, unless you have a ver good reason for a split.
Lennart
I am against installing million packages when I expect one. If I saw systemd-filesystem installed, then I would think that something needs to be placed into the systemd folder structure, but it was not worth of splitting into the separate package, e.g. small unit file. But when I see systemd and 5 other packages installed when I want to install subversion, that looks fishy to me.
Vít
On Tue, 26.08.14 14:22, Vít Ondruch (vondruch@redhat.com) wrote:
I am really against splitting things up into a million of subpackages, unless you have a ver good reason for a split.
I am against installing million packages when I expect one. If I saw systemd-filesystem installed, then I would think that something needs to be placed into the systemd folder structure, but it was not worth of splitting into the separate package, e.g. small unit file. But when I see systemd and 5 other packages installed when I want to install subversion, that looks fishy to me.
The init system of Fedora is systemd. What did you expect?
Lennart
If I saw systemd-filesystem installed, then I would think that something needs to be placed into the systemd folder structure,
Perhaps the bug is this: that you need to install a whole other RPM just to make a directory exist so you can put a file in it.
Why can't the RPM providing the file just make the directory and not have a dependency at all?
On Tue, Aug 26, 2014 at 10:46 AM, DJ Delorie dj@redhat.com wrote:
If I saw systemd-filesystem installed, then I would think that something needs to be placed into the systemd folder structure,
Perhaps the bug is this: that you need to install a whole other RPM just to make a directory exist so you can put a file in it.
Why can't the RPM providing the file just make the directory and not have a dependency at all?
As long your package doesn't need the package providing the directory for normal functionality, there's no reason not to have your package own that directory[1]. Packages that provide unit files, but are otherwise useful in the absence of systemd would probably fall into this category.
Rich
[1] https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_b...
Once upon a time, DJ Delorie dj@redhat.com said:
Perhaps the bug is this: that you need to install a whole other RPM just to make a directory exist so you can put a file in it.
Why can't the RPM providing the file just make the directory and not have a dependency at all?
It used to work (more or less) that way. The problem is when a directory is supposed to have specific ownership/permission settings, only the package that actually owns the directory has that configured. It doesn't make sense to try to put that info in every package (should the rsync RPM know the permissions of /usr/lib/systemd/system?).
On Tue, Aug 26, 2014 at 10:16:46AM -0500, Chris Adams wrote:
Once upon a time, DJ Delorie dj@redhat.com said:
Perhaps the bug is this: that you need to install a whole other RPM just to make a directory exist so you can put a file in it.
Why can't the RPM providing the file just make the directory and not have a dependency at all?
It used to work (more or less) that way. The problem is when a directory is supposed to have specific ownership/permission settings, only the package that actually owns the directory has that configured. It doesn't make sense to try to put that info in every package (should the rsync RPM know the permissions of /usr/lib/systemd/system?).
/usr/lib/systemd/system does not require any special mode. We actually now warn about files with anything but rw-rw-r-- mode. This is very unlikely to change.
The reason for dependency on systemd is different: if a package carries a systemd unit, it should usually be enabled according to presets. It should also be cleaned up when the package is removed. This requires a dependency on systemd which carries the preset settings and utilities to do this.
Zbyszek
On Wed, Aug 27, 2014 at 12:38:20AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
The reason for dependency on systemd is different: if a package carries a systemd unit, it should usually be enabled according to presets. It should also be cleaned up when the package is removed. This requires a dependency on systemd which carries the preset settings and utilities to do this.
Maybe better place for presets would be fedora-release-* package?
On Wed, Aug 27, 2014 at 08:38:44AM +0200, Tomasz Torcz wrote:
On Wed, Aug 27, 2014 at 12:38:20AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
The reason for dependency on systemd is different: if a package carries a systemd unit, it should usually be enabled according to presets. It should also be cleaned up when the package is removed. This requires a dependency on systemd which carries the preset settings and utilities to do this.
Maybe better place for presets would be fedora-release-* package?
This was discussed of fedora-devel [1], but in the end there doesn't seem to be a good home for the presets. In the end, having it in systemd is not too bad, especially that it makes systemd maintainers look at the unit files when they are added to presets to be enabled by default.
Zbyszek
[1] Thread titled "Proposal to WGs and rel-eng: Move 90-default.preset from systemd to fedora-release"
On Tue, Aug 26, 2014 at 12:59:23PM +0200, Vít Ondruch wrote:
- sytemd should consider to provide -filesystem package, which would
limit the dependency to single small package (but this might be return to the -units subpackage days? Not sure).
The directories can probably just be added to the filesystem package. Opening a bugzilla ticket usually helps here.
Regards Till
On 08/26/2014 04:59 AM, Vít Ondruch wrote:
Dne 26.8.2014 11:06, Michal Sekletar napsal(a):
On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
Hi,
Hi Vít,
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
At some point in time (F16 IIRC) we had systemd-units package which contained /etc/rpm/macros.systemd file. Packagers which followed our guidelines used for example %{unitdir} macro in %files. Hence they added systemd-units to BuildRequires.
These days systemd-units no longer exists, macro file moved to systemd rpm and systemd-units is a provided by systemd rpm.
Thank you for insightful explanation.
Nevertheless, if you are using some macro, it is just build time dependency. I believe that the issue might be due to %{unitdir} folder ownership. And I see two solutions:
- Packages which ships unit files should consider to put them into sub
package called either -daemon or -server. And this applies especially to packages such as man (forgot to mention this one previously), rsync or subversion. I don't typically use their server features or con jobs or whatever.
Looks like rsync now has a -daemon sub-package, as you requested, and which I think is a good thing.
https://bugzilla.redhat.com/show_bug.cgi?id=1123813
Wish it went with a -server name, as that seems much more common, especially for admin configurable services. Really wish we had more standardized names.
[root@vmrawhide ~]# yum list *-server | wc -l 137 [root@vmrawhide ~]# yum list *-daemon | wc -l 30
Dne 26.8.2014 19:12, Orion Poplawski napsal(a):
On 08/26/2014 04:59 AM, Vít Ondruch wrote:
Dne 26.8.2014 11:06, Michal Sekletar napsal(a):
On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
Hi,
Hi Vít,
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
At some point in time (F16 IIRC) we had systemd-units package which contained /etc/rpm/macros.systemd file. Packagers which followed our guidelines used for example %{unitdir} macro in %files. Hence they added systemd-units to BuildRequires.
These days systemd-units no longer exists, macro file moved to systemd rpm and systemd-units is a provided by systemd rpm.
Thank you for insightful explanation.
Nevertheless, if you are using some macro, it is just build time dependency. I believe that the issue might be due to %{unitdir} folder ownership. And I see two solutions:
- Packages which ships unit files should consider to put them into sub
package called either -daemon or -server. And this applies especially to packages such as man (forgot to mention this one previously), rsync or subversion. I don't typically use their server features or con jobs or whatever.
Looks like rsync now has a -daemon sub-package, as you requested, and which I think is a good thing.
https://bugzilla.redhat.com/show_bug.cgi?id=1123813
Wish it went with a -server name, as that seems much more common, especially for admin configurable services. Really wish we had more standardized names.
[root@vmrawhide ~]# yum list *-server | wc -l 137 [root@vmrawhide ~]# yum list *-daemon | wc -l 30
This was partially call for that standardization, although not explicit ;)
Vít
On 08/26/2014 04:59 AM, Vít Ondruch wrote:
- sytemd should consider to provide -filesystem package, which would
limit the dependency to single small package (but this might be return to the -units subpackage days? Not sure).
It's not (just) filesystem ownership, it's scriptlet processing:
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scriptl...
so you need systemctl
On Tue, 26.08.14 11:06, Michal Sekletar (msekleta@redhat.com) wrote:
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
At some point in time (F16 IIRC) we had systemd-units package which contained /etc/rpm/macros.systemd file. Packagers which followed our guidelines used for example %{unitdir} macro in %files. Hence they added systemd-units to BuildRequires.
These days systemd-units no longer exists, macro file moved to systemd rpm and systemd-units is a provided by systemd rpm. Therefore systemd proper creeping into buildroots.
Yeah, we removed the systemd-units package a while after systemd was the only init system we supported on Fedora...
Lennart
On Tue, 26.08.14 09:32, Vít Ondruch (vondruch@redhat.com) wrote:
Hi,
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
Lennart
Dne 26.8.2014 13:49, Lennart Poettering napsal(a):
On Tue, 26.08.14 09:32, Vít Ondruch (vondruch@redhat.com) wrote:
Hi,
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
Someone has to start somewhere. It is annoying to install several packages, when you expect that only one should be installed. And by coincidence, I met several of systemd dependencies during short period of time.
Vít
On Tue, 26.08.14 14:18, Vít Ondruch (vondruch@redhat.com) wrote:
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
Someone has to start somewhere. It is annoying to install several packages, when you expect that only one should be installed. And by coincidence, I met several of systemd dependencies during short period of time.
What I am not getting: what's the point? I mean, systemd is not exactly an optional package in Fedora.
You are asking people to split their packages in two, but what's the real reason for that? If the systemd package isn't optional anyway, why is this the dep you start with and asking people to complicate things for?
Lennart
Dne 26.8.2014 14:23, Lennart Poettering napsal(a):
On Tue, 26.08.14 14:18, Vít Ondruch (vondruch@redhat.com) wrote:
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
Someone has to start somewhere. It is annoying to install several packages, when you expect that only one should be installed. And by coincidence, I met several of systemd dependencies during short period of time.
What I am not getting: what's the point? I mean, systemd is not exactly an optional package in Fedora.
You are asking people to split their packages in two, but what's the real reason for that? If the systemd package isn't optional anyway, why is this the dep you start with and asking people to complicate things for?
Lennart
Isn't it optional? I am using mock and can build probably every ruby package without *systemd* package installed into the build root (I am not speaking about *systemd-libs*). But once I install one of man, subversion or rsync packages, systemd is suddenly pulled in, why? Why it should be?
You can try session like this yourself:
$ mock -r fedora-rawhide-i386 --init INFO: mock.py version 1.1.41 starting... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Start: lock buildroot Start: clean chroot INFO: chroot (/var/lib/mock/fedora-rawhide-i386) unlocked and deleted Finish: clean chroot Finish: lock buildroot Start: chroot init Start: lock buildroot Mock Version: 1.1.41 INFO: Mock Version: 1.1.41 INFO: calling preinit hooks INFO: enabled root cache Start: unpacking root cache Finish: unpacking root cache INFO: enabled yum cache Start: cleaning yum metadata Finish: cleaning yum metadata INFO: enabled ccache Start: device setup Finish: device setup Start: yum update Finish: yum update Finish: lock buildroot Finish: chroot init INFO: Installed packages: Finish: run
$ mock -r fedora-rawhide-i386 shell INFO: mock.py version 1.1.41 starting... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Start: lock buildroot Start: device setup Finish: device setup Start: shell
<mock-chroot>[root@unused-4-226 /]# svn --help bash: svn: command not found
<mock-chroot>[root@unused-4-226 /]# # Ah, no subversion
<mock-chroot>[root@unused-4-226 /]# logout Finish: shell Finish: lock buildroot
$ mock -r fedora-rawhide-i386 --install subversion INFO: mock.py version 1.1.41 starting... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Mock Version: 1.1.41 INFO: Mock Version: 1.1.41 Start: lock buildroot INFO: installing package(s): subversion INFO: ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: subversion i686 1.8.10-2.fc22 fedora 1.2 M Installing for dependencies: acl i686 2.2.52-7.fc22 fedora 76 k apr i686 1.5.1-3.fc22 fedora 118 k apr-util i686 1.5.3-3.fc22 fedora 98 k cryptsetup-libs i686 1.6.6-1.fc22 fedora 188 k dbus i686 1:1.8.6-3.fc22 fedora 332 k dbus-libs i686 1:1.8.6-3.fc22 fedora 169 k device-mapper i686 1.02.88-2.fc22 fedora 221 k device-mapper-libs i686 1.02.88-2.fc22 fedora 276 k fipscheck i686 1.4.1-7.fc22 fedora 25 k fipscheck-lib i686 1.4.1-7.fc22 fedora 15 k kmod i686 18-3.fc22 fedora 112 k kmod-libs i686 18-3.fc22 fedora 62 k libseccomp i686 2.1.1-5.fc22 fedora 44 k libserf i686 1.3.7-2.fc22 fedora 58 k python i686 2.7.8-6.fc22 fedora 91 k qrencode-libs i686 3.4.2-4.fc22 fedora 56 k subversion-libs i686 1.8.10-2.fc22 fedora 1.1 M systemd i686 216-2.fc22 fedora 4.9 M
Transaction Summary ================================================================================ Install 1 Package (+18 Dependent packages)
Total size: 9.1 M Total download size: 2.6 M Installed size: 33 M http://less.cogeco.net/fedora/linux/development/rawhide/i386/os/Packages/a/a...: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. http://less.cogeco.net/fedora/linux/development/rawhide/i386/os/Packages/s/s...: [Errno 14] HTTP Error 404 - Not Found Trying other mirror.
Installed: subversion.i686 0:1.8.10-2.fc22
Dependency Installed: acl.i686 0:2.2.52-7.fc22 apr.i686 0:1.5.1-3.fc22 apr-util.i686 0:1.5.3-3.fc22 cryptsetup-libs.i686 0:1.6.6-1.fc22 dbus.i686 1:1.8.6-3.fc22 dbus-libs.i686 1:1.8.6-3.fc22 device-mapper.i686 0:1.02.88-2.fc22 device-mapper-libs.i686 0:1.02.88-2.fc22 fipscheck.i686 0:1.4.1-7.fc22 fipscheck-lib.i686 0:1.4.1-7.fc22 kmod.i686 0:18-3.fc22 kmod-libs.i686 0:18-3.fc22 libseccomp.i686 0:2.1.1-5.fc22 libserf.i686 0:1.3.7-2.fc22 python.i686 0:2.7.8-6.fc22 qrencode-libs.i686 0:3.4.2-4.fc22 subversion-libs.i686 0:1.8.10-2.fc22 systemd.i686 0:216-2.fc22
Finish: lock buildroot Finish: run
I would expect that I'll install subversion, may be some other small library, but I don't expect to install 33 MB of stuff in 18 packages.
Vít
Dne 26.8.2014 14:55, Vít Ondruch napsal(a):
Dne 26.8.2014 14:23, Lennart Poettering napsal(a):
On Tue, 26.08.14 14:18, Vít Ondruch (vondruch@redhat.com) wrote:
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
Someone has to start somewhere. It is annoying to install several packages, when you expect that only one should be installed. And by coincidence, I met several of systemd dependencies during short period of time.
What I am not getting: what's the point? I mean, systemd is not exactly an optional package in Fedora.
You are asking people to split their packages in two, but what's the real reason for that? If the systemd package isn't optional anyway, why is this the dep you start with and asking people to complicate things for?
Lennart
Isn't it optional? I am using mock and can build probably every ruby package without *systemd* package installed into the build root (I am not speaking about *systemd-libs*). But once I install one of man, subversion or rsync packages, systemd is suddenly pulled in, why? Why it should be?
You can try session like this yourself:
$ mock -r fedora-rawhide-i386 --init INFO: mock.py version 1.1.41 starting... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Start: lock buildroot Start: clean chroot INFO: chroot (/var/lib/mock/fedora-rawhide-i386) unlocked and deleted Finish: clean chroot Finish: lock buildroot Start: chroot init Start: lock buildroot Mock Version: 1.1.41 INFO: Mock Version: 1.1.41 INFO: calling preinit hooks INFO: enabled root cache Start: unpacking root cache Finish: unpacking root cache INFO: enabled yum cache Start: cleaning yum metadata Finish: cleaning yum metadata INFO: enabled ccache Start: device setup Finish: device setup Start: yum update Finish: yum update Finish: lock buildroot Finish: chroot init INFO: Installed packages: Finish: run
$ mock -r fedora-rawhide-i386 shell INFO: mock.py version 1.1.41 starting... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Start: lock buildroot Start: device setup Finish: device setup Start: shell
<mock-chroot>[root@unused-4-226 /]# svn --help bash: svn: command not found
<mock-chroot>[root@unused-4-226 /]# # Ah, no subversion
<mock-chroot>[root@unused-4-226 /]# logout Finish: shell Finish: lock buildroot
$ mock -r fedora-rawhide-i386 --install subversion INFO: mock.py version 1.1.41 starting... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Mock Version: 1.1.41 INFO: Mock Version: 1.1.41 Start: lock buildroot INFO: installing package(s): subversion INFO: ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: subversion i686 1.8.10-2.fc22 fedora 1.2 M Installing for dependencies: acl i686 2.2.52-7.fc22 fedora 76 k apr i686 1.5.1-3.fc22 fedora 118 k apr-util i686 1.5.3-3.fc22 fedora 98 k cryptsetup-libs i686 1.6.6-1.fc22 fedora 188 k dbus i686 1:1.8.6-3.fc22 fedora 332 k dbus-libs i686 1:1.8.6-3.fc22 fedora 169 k device-mapper i686 1.02.88-2.fc22 fedora 221 k device-mapper-libs i686 1.02.88-2.fc22 fedora 276 k fipscheck i686 1.4.1-7.fc22 fedora 25 k fipscheck-lib i686 1.4.1-7.fc22 fedora 15 k kmod i686 18-3.fc22 fedora 112 k kmod-libs i686 18-3.fc22 fedora 62 k libseccomp i686 2.1.1-5.fc22 fedora 44 k libserf i686 1.3.7-2.fc22 fedora 58 k python i686 2.7.8-6.fc22 fedora 91 k qrencode-libs i686 3.4.2-4.fc22 fedora 56 k subversion-libs i686 1.8.10-2.fc22 fedora 1.1 M systemd i686 216-2.fc22 fedora 4.9 M
Transaction Summary
Install 1 Package (+18 Dependent packages)
Total size: 9.1 M Total download size: 2.6 M Installed size: 33 M http://less.cogeco.net/fedora/linux/development/rawhide/i386/os/Packages/a/a...: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. http://less.cogeco.net/fedora/linux/development/rawhide/i386/os/Packages/s/s...: [Errno 14] HTTP Error 404 - Not Found Trying other mirror.
Installed: subversion.i686 0:1.8.10-2.fc22
Dependency Installed: acl.i686 0:2.2.52-7.fc22 apr.i686 0:1.5.1-3.fc22 apr-util.i686 0:1.5.3-3.fc22 cryptsetup-libs.i686 0:1.6.6-1.fc22 dbus.i686 1:1.8.6-3.fc22 dbus-libs.i686 1:1.8.6-3.fc22 device-mapper.i686 0:1.02.88-2.fc22 device-mapper-libs.i686 0:1.02.88-2.fc22 fipscheck.i686 0:1.4.1-7.fc22 fipscheck-lib.i686 0:1.4.1-7.fc22 kmod.i686 0:18-3.fc22 kmod-libs.i686 0:18-3.fc22 libseccomp.i686 0:2.1.1-5.fc22 libserf.i686 0:1.3.7-2.fc22 python.i686 0:2.7.8-6.fc22 qrencode-libs.i686 0:3.4.2-4.fc22 subversion-libs.i686 0:1.8.10-2.fc22 systemd.i686 0:216-2.fc22
Finish: lock buildroot Finish: run
I would expect that I'll install subversion, may be some other small library, but I don't expect to install 33 MB of stuff in 18 packages.
Vít
This is what could be probably saved, if systemd is not installed:
$ mock -r fedora-rawhide-i386 --install systemd INFO: mock.py version 1.1.41 starting... Start: init plugins INFO: selinux enabled Finish: init plugins Start: run Mock Version: 1.1.41 INFO: Mock Version: 1.1.41 Start: lock buildroot INFO: installing package(s): systemd INFO: ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: systemd i686 216-2.fc22 fedora 4.9 M Installing for dependencies: acl i686 2.2.52-7.fc22 fedora 76 k cryptsetup-libs i686 1.6.6-1.fc22 fedora 188 k dbus i686 1:1.8.6-3.fc22 fedora 332 k dbus-libs i686 1:1.8.6-3.fc22 fedora 169 k device-mapper i686 1.02.88-2.fc22 fedora 221 k device-mapper-libs i686 1.02.88-2.fc22 fedora 276 k fipscheck i686 1.4.1-7.fc22 fedora 25 k fipscheck-lib i686 1.4.1-7.fc22 fedora 15 k kmod i686 18-3.fc22 fedora 112 k kmod-libs i686 18-3.fc22 fedora 62 k libseccomp i686 2.1.1-5.fc22 fedora 44 k qrencode-libs i686 3.4.2-4.fc22 fedora 56 k
Transaction Summary ================================================================================ Install 1 Package (+12 Dependent packages)
Total size: 6.5 M Installed size: 24 M
Installed: systemd.i686 0:216-2.fc22
Dependency Installed: acl.i686 0:2.2.52-7.fc22 cryptsetup-libs.i686 0:1.6.6-1.fc22 dbus.i686 1:1.8.6-3.fc22 dbus-libs.i686 1:1.8.6-3.fc22 device-mapper.i686 0:1.02.88-2.fc22 device-mapper-libs.i686 0:1.02.88-2.fc22 fipscheck.i686 0:1.4.1-7.fc22 fipscheck-lib.i686 0:1.4.1-7.fc22 kmod.i686 0:18-3.fc22 kmod-libs.i686 0:18-3.fc22 libseccomp.i686 0:2.1.1-5.fc22 qrencode-libs.i686 0:3.4.2-4.fc22
Finish: lock buildroot Finish: run
I hope you can do the diff yourself.
Vít
On 26. 8. 2014 at 14:55:34, Vít Ondruch wrote:
Dne 26.8.2014 14:23, Lennart Poettering napsal(a):
On Tue, 26.08.14 14:18, Vít Ondruch (vondruch@redhat.com) wrote:
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into
independent
subpackages. When I install rsync/subversion, I am typically interested just in client side.
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd
package.
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
Someone has to start somewhere. It is annoying to install several packages, when you expect that only one should be installed. And by coincidence, I met several of systemd dependencies during short period of time.
What I am not getting: what's the point? I mean, systemd is not exactly an optional package in Fedora.
You are asking people to split their packages in two, but what's the real reason for that? If the systemd package isn't optional anyway, why is this the dep you start with and asking people to complicate things for?
Lennart
Isn't it optional? I am using mock and can build probably every ruby package without *systemd* package installed into the build root (I am not speaking about *systemd-libs*). But once I install one of man, subversion or rsync packages, systemd is suddenly pulled in, why? Why it should be?
I have to agree with Vít here. Unnecessary dependencies are not something anyone should be advocating, whatever the reason might be.
By the same logic you offer, systemd dependencies can be removed from all of the mentioned packages, as it's safe to assume systemd is core part of the system and will therefore be installed.
Thanks Jan
On Tue, 26.08.14 14:55, Vít Ondruch (vondruch@redhat.com) wrote:
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
Someone has to start somewhere. It is annoying to install several packages, when you expect that only one should be installed. And by coincidence, I met several of systemd dependencies during short period of time.
What I am not getting: what's the point? I mean, systemd is not exactly an optional package in Fedora.
You are asking people to split their packages in two, but what's the real reason for that? If the systemd package isn't optional anyway, why is this the dep you start with and asking people to complicate things for?
Isn't it optional? I am using mock and can build probably every ruby package without *systemd* package installed into the build root (I am not speaking about *systemd-libs*). But once I install one of man, subversion or rsync packages, systemd is suddenly pulled in, why? Why it should be?
I am not doubting that one can minimize things, and that currently systemd ends up being into the build-root quite often. I am just wondering what the big deal is.
I mean, if it is really the goal of Fedora to minimize deps, and split everything up like Debian is doing it (where for example every single library .so must be a .deb of its own), then that's OK, but so far that's not how Fedora has been doing things. And I am pretty sure if you want to change that, that you then should go through FESCO first...
Honestly, I kinda like the pragmatism on Fedora, so far, that there's no need to split up packages into a myriad of mini packges. And I think that texlive packaging is an absolute disaster, where things are split up to the maximum possible (> 20% of the packages I have on my machine now are texlive packages, just because i use latex beamer from time to time...)
Of course, this kind of pragmatism makes bootstrapping fedora on some new arch harder, but then again, it conceptually is much easer to grok for admins what packages do what if there are fewer...
Lennart
On 26 August 2014 10:43, Lennart Poettering mzerqung@0pointer.de wrote:
On Tue, 26.08.14 14:55, Vít Ondruch (vondruch@redhat.com) wrote:
Just to be clear, systemd-libs is in minimal build root already, so
I am
not complaining about systemd-libs package, but about systemd
package.
What's the rationale here? I mean, we have so many dependencies, if
you
want to minimize them, you have a loooong way to go...
Someone has to start somewhere. It is annoying to install several packages, when you expect that only one should be installed. And by coincidence, I met several of systemd dependencies during short period of time.
What I am not getting: what's the point? I mean, systemd is not exactly an optional package in Fedora.
You are asking people to split their packages in two, but what's the real reason for that? If the systemd package isn't optional anyway, why is this the dep you start with and asking people to complicate things for?
Isn't it optional? I am using mock and can build probably every ruby package without *systemd* package installed into the build root (I am not speaking about *systemd-libs*). But once I install one of man, subversion or rsync packages, systemd is suddenly pulled in, why? Why it should be?
I am not doubting that one can minimize things, and that currently systemd ends up being into the build-root quite often. I am just wondering what the big deal is.
So after looking at several different container images kickstarts I notice they all seem to remove systemd as it is provided by the base systemd of the system. I don't know if that is the correct method or not, but seems to be the common practice. So if various services end up relying on systemd and would be removed in making an image.. what is the proper method?
Once upon a time, Stephen John Smoogen smooge@gmail.com said:
So after looking at several different container images kickstarts I notice they all seem to remove systemd as it is provided by the base systemd of the system. I don't know if that is the correct method or not, but seems to be the common practice. So if various services end up relying on systemd and would be removed in making an image.. what is the proper method?
Yeah, saying a spreading systemd dependency is okay because "Fedora uses systemd" is just IMHO a lazy excuse. There are deployments like containers that _don't_ use systemd, and don't want to pull it in.
There is no excuse for something like rsync depending on systemd. The majority of rsync usage for most system admins and such (deployment, backups, etc.) does not use the rsync-as-a-service setup, but is run over SSH (usually with keys). I use rsync on the desktop all the time, and I certainly don't run it is a service there. The only time I've run the rsync service was when I ran a public Fedora mirror server. The rsync-as-a-service either should be split into a separate subpackage, or a common package like filesystem should provide the requisite directories.
Looking at the rsync packaging, it includes the standard (macro provided I believe) postinstall/preuninstall/postuninstall scripts that also call systemctl, so in this case, the dep is not just on the directory. So, the practical solution is to split rsync into two packages, with an rsync-service subpackage that has all the systemd integration.
On Tue, Aug 26, 2014 at 1:38 PM, Chris Adams linux@cmadams.net wrote:
Once upon a time, Stephen John Smoogen smooge@gmail.com said:
So after looking at several different container images kickstarts I notice they all seem to remove systemd as it is provided by the base systemd of the system. I don't know if that is the correct method or not, but seems to be the common practice. So if various services end up relying on systemd and would be removed in making an image.. what is the proper method?
Yeah, saying a spreading systemd dependency is okay because "Fedora uses systemd" is just IMHO a lazy excuse. There are deployments like containers that _don't_ use systemd, and don't want to pull it in.
Yeah, that's a fair point.
There is no excuse for something like rsync depending on systemd. The majority of rsync usage for most system admins and such (deployment, backups, etc.) does not use the rsync-as-a-service setup, but is run over SSH (usually with keys). I use rsync on the desktop all the time, and I certainly don't run it is a service there. The only time I've run the rsync service was when I ran a public Fedora mirror server. The rsync-as-a-service either should be split into a separate subpackage, or a common package like filesystem should provide the requisite directories.
Looking at the rsync packaging, it includes the standard (macro provided I believe) postinstall/preuninstall/postuninstall scripts that also call systemctl, so in this case, the dep is not just on the directory. So, the practical solution is to split rsync into two packages, with an rsync-service subpackage that has all the systemd integration.
Would you be willing to craft a patch and send it to the rsync maintainer to do that?
josh
Once upon a time, Josh Boyer jwboyer@gmail.com said:
Would you be willing to craft a patch and send it to the rsync maintainer to do that?
I believe (later in this thread) someone said that has already been done, as "rsync-daemon".
On Tue, Aug 26, 2014 at 1:56 PM, Chris Adams linux@cmadams.net wrote:
Once upon a time, Josh Boyer jwboyer@gmail.com said:
Would you be willing to craft a patch and send it to the rsync maintainer to do that?
I believe (later in this thread) someone said that has already been done, as "rsync-daemon".
Excellent. Missed that. Thank you.
josh
On Tuesday 26 August 2014 18:43:22 Lennart Poettering wrote:
Honestly, I kinda like the pragmatism on Fedora, so far, that there's no need to split up packages into a myriad of mini packges. And I think that texlive packaging is an absolute disaster, where things are split up to the maximum possible (> 20% of the packages I have on my machine now are texlive packages, just because i use latex beamer from time to time...)
This is an argument that I have seen repetitively in this list.
In my point of view the texlive split is similar to the perl-* or python-* packages.
In this case texlive is a meta-package (distribution) that has most of the (la)tex packages that can be shipped in Fedora.
To propose just a few texlive packages is similar to to have a few meta-packages called perl-extras or python-extras, with python-full, or perl-network. If this scheme does not make sense to python, or perl, or any other language why does it makes sense to apply it to latex packages?
On 2014-08-26, José Matos jamatos@fc.up.pt wrote:
In my point of view the texlive split is similar to the perl-* or python-* packages.
The reason for the split is the same---upstream develops the texlive classes independently in separate packages and publish them on CTAN.
The difference between TeX and Perl packages in Fedora is that dependencies between Perl packages are manually reviewed and corrected when needed (especially the fuzzy "weak" dependecies), while TeX packages are generated automatically with incorrect dependencies taken from upstream.
Therefore the Fedora TeX packages are hard to use. One need to give love to the package maintenance. That's my opinion why fully automated repackaging, as requested by some visionaries, will never provide good results. (Actually, Java SIG started to patch the upstream dependency definitions but I don't how the changes are accepted by the upstream. I had a bad experience regarding Perl upstream.)
-- Petr
Dne 26.8.2014 18:43, Lennart Poettering napsal(a):
On Tue, 26.08.14 14:55, Vít Ondruch (vondruch@redhat.com) wrote:
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
Someone has to start somewhere. It is annoying to install several packages, when you expect that only one should be installed. And by coincidence, I met several of systemd dependencies during short period of time.
What I am not getting: what's the point? I mean, systemd is not exactly an optional package in Fedora.
You are asking people to split their packages in two, but what's the real reason for that? If the systemd package isn't optional anyway, why is this the dep you start with and asking people to complicate things for?
Isn't it optional? I am using mock and can build probably every ruby package without *systemd* package installed into the build root (I am not speaking about *systemd-libs*). But once I install one of man, subversion or rsync packages, systemd is suddenly pulled in, why? Why it should be?
I am not doubting that one can minimize things, and that currently systemd ends up being into the build-root quite often. I am just wondering what the big deal is.
I mean, if it is really the goal of Fedora to minimize deps, and split everything up like Debian is doing it (where for example every single library .so must be a .deb of its own), then that's OK, but so far that's not how Fedora has been doing things. And I am pretty sure if you want to change that, that you then should go through FESCO first...
Honestly, I kinda like the pragmatism on Fedora, so far, that there's no need to split up packages into a myriad of mini packges. And I think that texlive packaging is an absolute disaster, where things are split up to the maximum possible (> 20% of the packages I have on my machine now are texlive packages, just because i use latex beamer from time to time...)
Of course, this kind of pragmatism makes bootstrapping fedora on some new arch harder, but then again, it conceptually is much easer to grok for admins what packages do what if there are fewer...
Lennart
Actually I agree with you on the pragmatism. That is why I started this thread with "Please consider moving daemon parts into independent subpackages". This also implies that you should think about dependencies and if somebody raises hand, you should be open to discussion/reconsideration.
And no, this is not just about systemd, the unnecessary dependencies creeps in also in other libraries. openal-soft is similar example from another bucket which pulls in Qt [1] (and this ticket was promptly resolved, thanks).
Vít
On 08/26/2014 08:23 AM, Lennart Poettering wrote:
On Tue, 26.08.14 14:18, Vít Ondruch (vondruch@redhat.com) wrote:
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
Someone has to start somewhere. It is annoying to install several packages, when you expect that only one should be installed. And by coincidence, I met several of systemd dependencies during short period of time.
What I am not getting: what's the point? I mean, systemd is not exactly an optional package in Fedora.
You are asking people to split their packages in two, but what's the real reason for that? If the systemd package isn't optional anyway, why is this the dep you start with and asking people to complicate things for?
Lennart
Well it is optional in docker container images.
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
When I bootstrapped Fedora for ARM way back when, I had to deal with these dependencies. A lot. Finding a minimal set of RPMs to cross-compile to get a bootable core was very difficult because of dependencies, and managing the path up to koji was a nightmare. Even after that, there were some packages that couldn't be built *at all* because of circuilar dependencies or dependencies on them.
So, to all of you who say "oh well" to dependencies... I hate you.
Seriously. Not only have you made my personal job miserable for a while, but you demonstrate the worst traits of engineering. If there's a problem, you don't hide it or just "let it be because we're used to it." You *fix* it. And you make sure it *stays* fixed. Take some pride in your work! Do the best you can! If you're only willing to do mediocre work and let problems exist because you can't be bothered to fix them, then Fedora will at best be a mediocre product.
On Tue, Aug 26, 2014 at 10:44 AM, DJ Delorie dj@redhat.com wrote:
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
When I bootstrapped Fedora for ARM way back when, I had to deal with these dependencies. A lot. Finding a minimal set of RPMs to cross-compile to get a bootable core was very difficult because of dependencies, and managing the path up to koji was a nightmare. Even after that, there were some packages that couldn't be built *at all* because of circuilar dependencies or dependencies on them.
So, to all of you who say "oh well" to dependencies... I hate you.
Seriously. Not only have you made my personal job miserable for a while, but you demonstrate the worst traits of engineering. If there's a problem, you don't hide it or just "let it be because we're used to it." You *fix* it. And you make sure it *stays* fixed. Take some pride in your work! Do the best you can! If you're only willing to do mediocre work and let problems exist because you can't be bothered to fix them, then Fedora will at best be a mediocre product.
Your message is likely to be lost because your tone is basically an attack. It's pretty unwarranted as well. People don't add dependencies just for the hell of it. They grow over time like any software bloat, and usually make sense at the time they're added.
FWIW, I agree the dependency issues can be a problem. I just wish you wouldn't have resorted to being so negative.
josh
On Tue, 26.08.14 10:44, DJ Delorie (dj@redhat.com) wrote:
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
When I bootstrapped Fedora for ARM way back when, I had to deal with these dependencies. A lot. Finding a minimal set of RPMs to
Well, Fedora is not a distribution that cares about whether it is easily bootstrappable. It never was a goal to be one. If you want to make it one, then that's fine, but that'd be something to make an official goal first, by going through FESCO...
If you want a distro that is bootstrappable, the way that Gentoo is, or that Debian tries to be then that's OK. I personally don't think it is worth the effort though, as we don't have to bootstrap new archs every other week...
cross-compile to get a bootable core was very difficult because of dependencies, and managing the path up to koji was a nightmare. Even after that, there were some packages that couldn't be built *at all* because of circuilar dependencies or dependencies on them.
Cyclic dependencies are something that so far was accepted in Fedora. If you want to get rid of that, then make it a Fedora goal...
For many packages getting rid of the cyclic deps would mean having to build things twice, but I am not sure this is really worth the work...
So, to all of you who say "oh well" to dependencies... I hate you.
Seriously. Not only have you made my personal job miserable for a while, but you demonstrate the worst traits of engineering. If there's a problem, you don't hide it or just "let it be because we're used to it." You *fix* it. And you make sure it *stays* fixed. Take some pride in your work! Do the best you can! If you're only willing to do mediocre work and let problems exist because you can't be bothered to fix them, then Fedora will at best be a mediocre product.
You know, some cyclic des might be easy to resolve, but a big chunk really isn't. And our core OS stuff is full of it. I think you underestiate the complexity of this.
Lennart
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
When I bootstrapped Fedora for ARM way back when, I had to deal with these dependencies. A lot. Finding a minimal set of RPMs to
Well, Fedora is not a distribution that cares about whether it is easily bootstrappable. It never was a goal to be one. If you want to make it one, then that's fine, but that'd be something to make an official goal first, by going through FESCO...
If you want a distro that is bootstrappable, the way that Gentoo is, or that Debian tries to be then that's OK. I personally don't think it is worth the effort though, as we don't have to bootstrap new archs every other week...
I believe that's something that the Base working group is actually actively trying to achieve, Phil or one of the members might be able to comment further on their exact plans for this.
cross-compile to get a bootable core was very difficult because of dependencies, and managing the path up to koji was a nightmare. Even after that, there were some packages that couldn't be built *at all* because of circuilar dependencies or dependencies on them.
Cyclic dependencies are something that so far was accepted in Fedora. If you want to get rid of that, then make it a Fedora goal...
For many packages getting rid of the cyclic deps would mean having to build things twice, but I am not sure this is really worth the work...
Well if you can set a boostrap flag in the distro, run a set of builds, unset the flag, bump and rebuild it's really not that much work,
So, to all of you who say "oh well" to dependencies... I hate you.
Seriously. Not only have you made my personal job miserable for a while, but you demonstrate the worst traits of engineering. If there's a problem, you don't hide it or just "let it be because we're used to it." You *fix* it. And you make sure it *stays* fixed. Take some pride in your work! Do the best you can! If you're only willing to do mediocre work and let problems exist because you can't be bothered to fix them, then Fedora will at best be a mediocre product.
You know, some cyclic des might be easy to resolve, but a big chunk really isn't. And our core OS stuff is full of it. I think you underestiate the complexity of this.
There's actually been some analysis done of this and people are actively working to reduce them.
Peter
On Tue, Aug 26, 2014 at 07:15:46PM +0100, Peter Robinson wrote:
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
When I bootstrapped Fedora for ARM way back when, I had to deal with these dependencies. A lot. Finding a minimal set of RPMs to
Well, Fedora is not a distribution that cares about whether it is easily bootstrappable. It never was a goal to be one. If you want to make it one, then that's fine, but that'd be something to make an official goal first, by going through FESCO...
If you want a distro that is bootstrappable, the way that Gentoo is, or that Debian tries to be then that's OK. I personally don't think it is worth the effort though, as we don't have to bootstrap new archs every other week...
I believe that's something that the Base working group is actually actively trying to achieve, Phil or one of the members might be able to comment further on their exact plans for this.
I think splitting out a subpackage (let's call it systemd-filesystem for now) to reduce the dependencies would be useful. But it would have to be done properly, in a way that behaviour is preserved, i.e. that macros provided by /usr/lib/rpm/macros.d/macros.systemd continue to do something sensible. Currently the dependency ensures that when the system is bootstrapped, those packages are installed after systemd. The macros would have to be modified to give an identical result if systemd is installed later.
Looking at the list, those macros call udevadm, journalctl, systemd-tmpfiles, systemd-sysusers, systemd-sysctl, systemd-binfmt. If systemd was not installed the calls to systemctl stop/daemon-reload/try-restart and udevadm control should become noops. Calls to systemd-binfmt, systemd-sysctl, systemd-tmpfiles --create can be noops too, with the understanding that the functionality will not be available until systemd is installed and those services (systemd-tmpfiles.service, systemd-binfmt.service, systemd-sysctl.service) are started. Calls to systemctl preset/disable and udevadm hwdb --update, systemd-sysusers, journalctl --update-catalog would have to tweaked so that they run without systemd. They already either do that or support that functionality with some switches, so it would be possible to tweak the macros to do that. If systemd was installed later, it would pick up the updated configuration from the filesystem.
I'm rejecting the idea of reimplementing the functionality. I think it only makes sense is possible with existing binaries.
With this assumption, it seems feasible to split out "systemd-filesystem", but it would have to contain systemctl, journalctl, udevadm, and systemd-sysusers binaries. It's hard to say exactly what dependencies would be shared with the main package, but probably almost all of the libraries, including cryptographic and compression and selinux... So I think that the savings would be modest. Probably the most important: dbus, pam, seccomp, audit.
Also, this would not help the problem with arch bootstrapping, since everything would still be built from one source package.
I'm not sure if people would still find that useful.
Zbyszek
On 08/26/2014 08:15 PM, Peter Robinson wrote:
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
When I bootstrapped Fedora for ARM way back when, I had to deal with these dependencies. A lot. Finding a minimal set of RPMs to
Well, Fedora is not a distribution that cares about whether it is easily bootstrappable. It never was a goal to be one. If you want to make it one, then that's fine, but that'd be something to make an official goal first, by going through FESCO...
If you want a distro that is bootstrappable, the way that Gentoo is, or that Debian tries to be then that's OK. I personally don't think it is worth the effort though, as we don't have to bootstrap new archs every other week...
I believe that's something that the Base working group is actually actively trying to achieve, Phil or one of the members might be able to comment further on their exact plans for this.
cross-compile to get a bootable core was very difficult because of dependencies, and managing the path up to koji was a nightmare. Even after that, there were some packages that couldn't be built *at all* because of circuilar dependencies or dependencies on them.
Cyclic dependencies are something that so far was accepted in Fedora. If you want to get rid of that, then make it a Fedora goal...
For many packages getting rid of the cyclic deps would mean having to build things twice, but I am not sure this is really worth the work...
Well if you can set a boostrap flag in the distro, run a set of builds, unset the flag, bump and rebuild it's really not that much work,
So, to all of you who say "oh well" to dependencies... I hate you.
Seriously. Not only have you made my personal job miserable for a while, but you demonstrate the worst traits of engineering. If there's a problem, you don't hide it or just "let it be because we're used to it." You *fix* it. And you make sure it *stays* fixed. Take some pride in your work! Do the best you can! If you're only willing to do mediocre work and let problems exist because you can't be bothered to fix them, then Fedora will at best be a mediocre product.
You know, some cyclic des might be easy to resolve, but a big chunk really isn't. And our core OS stuff is full of it. I think you underestiate the complexity of this.
There's actually been some analysis done of this and people are actively working to reduce them.
Peter
Thanks for your words. I was waiting for someone from Base WG, who will say we are working on it! At least I thought Base WG was trying to make easier bootstrap for additional architectures and for images.
Bootstraping macros for breaking cycles are used by some languages and it would be great to do similar work for whole distribution. Removal of optional dependencies from main package will be also useful, when Fedora will produce Docker images.
Marcela
On 08/26/2014 08:15 PM, Peter Robinson wrote:
What's the rationale here? I mean, we have so many dependencies, if you want to minimize them, you have a loooong way to go...
When I bootstrapped Fedora for ARM way back when, I had to deal with these dependencies. A lot. Finding a minimal set of RPMs to
Well, Fedora is not a distribution that cares about whether it is easily bootstrappable. It never was a goal to be one. If you want to make it one, then that's fine, but that'd be something to make an official goal first, by going through FESCO...
If you want a distro that is bootstrappable, the way that Gentoo is, or that Debian tries to be then that's OK. I personally don't think it is worth the effort though, as we don't have to bootstrap new archs every other week...
I believe that's something that the Base working group is actually actively trying to achieve, Phil or one of the members might be able to comment further on their exact plans for this.
Right. So the main focus right now is first of all cleaning up what buildrequires we have and targeting the things that would will make a big difference.
For one thats the work Benedikt Morbach has been working on over the past 2 months in regards to automatically finding potentially unnecessary buildrequires and then working with upstream and Fedora maintainers on fixing them.
The next topic we've started looking at is more related to the bootstrapping. Granted, we don't do that every release, but as the past several years has show us new architectures can pop up rather quickly, and bootstrapping Fedora right now is a real pain as me, Peter and Dennis can attest to.
But there the issue is more cyclic dependencies, especially among core components. As long as we get those fixed the rest will be "relatively" easy. It's still much more than a simple rpmbuild --rebuild foo.srpm, but a goal would be to get to that state without having to jump through 3 very heavily scripted and hacked manual stages with lots of ugly stuff in the builds happening there.
I agree though that this is relatively unimportant for everyday operation in Fedora (or any distribution for that matter) and a typical developer/maintainer probably doesn't care (and probably shouldn't, really).
Now, coming to systemd and the requirements there, i'm all for removing unnecessary requirements, and especially with our increasing focus on containerized applications and images (e.g. docker or similar) i'd love to see very lean images by default being constructed with default packages without any post install hacks again, so i'd personally appreciate it if that would be fixed, but it's certainly not the end of the world if it isn't and by far less severe than other disasters that happened in packaging in Fedora (see texlive, but we're trying to fix some of that insanity).
I'm less inclined to agree with the argument for mock and builds now taking much longer to run due to these requirements. Looking at some of the examples (and having run a few of my own), the typical additional number of packages with or without the subpackage is usually very low (aka, below 10) and won't affect build time drastically.
cross-compile to get a bootable core was very difficult because of dependencies, and managing the path up to koji was a nightmare. Even after that, there were some packages that couldn't be built *at all* because of circuilar dependencies or dependencies on them.
Cyclic dependencies are something that so far was accepted in Fedora. If you want to get rid of that, then make it a Fedora goal...
For many packages getting rid of the cyclic deps would mean having to build things twice, but I am not sure this is really worth the work...
Well if you can set a boostrap flag in the distro, run a set of builds, unset the flag, bump and rebuild it's really not that much work,
Aye, but thats still work that we have to flash out in more detail and then get someone actively really working on it. The basic principle is "easy" (see the bootstrap flag in the perl-* packages), but making sure it is being properly done and maintained is a different matter.
So, to all of you who say "oh well" to dependencies... I hate you.
Seriously. Not only have you made my personal job miserable for a while, but you demonstrate the worst traits of engineering. If there's a problem, you don't hide it or just "let it be because we're used to it." You *fix* it. And you make sure it *stays* fixed. Take some pride in your work! Do the best you can! If you're only willing to do mediocre work and let problems exist because you can't be bothered to fix them, then Fedora will at best be a mediocre product.
You know, some cyclic des might be easy to resolve, but a big chunk really isn't. And our core OS stuff is full of it. I think you underestiate the complexity of this.
There's actually been some analysis done of this and people are actively working to reduce them.
Peter
Exactly, as i've said, doing that manually is rather insane (see http://www.harald-hoyer.de/2014/01/14/self-hosting-fedora-base/ for some funny graphics regarding this), and the dependency creep that happened in Fedora over the past 10+ years is really the cause of it.
So addressing this and focusing then on the 80% of the real issues instead of picking and tiny bits left and right will yield a much bigger bang for the buck, therefore as long as systemd itself doesn't start to do cyclic dependencies i'm personally fine with it being pulled in occasionally.
Thanks & regards, Phil
On 2014-08-26 11:55, Lennart Poettering wrote:
Well, Fedora is not a distribution that cares about whether it is easily bootstrappable. It never was a goal to be one. If you want to make it one, then that's fine, but that'd be something to make an official goal first, by going through FESCO...
If you want a distro that is bootstrappable, the way that Gentoo is, or that Debian tries to be then that's OK. I personally don't think it is worth the effort though, as we don't have to bootstrap new archs every other week...
Both aarch64 and ppc64le were introduced in a relatively short amount of time. As someone who helped bootstrap a new platform (and a relatively obscure one at that) last year, the last thing we need to do is make this process harder than necessary.
On Tue, Aug 26, 2014 at 06:55:36PM +0200, Lennart Poettering wrote:
Well, Fedora is not a distribution that cares about whether it is easily bootstrappable. It never was a goal to be one. If you want to make it one, then that's fine, but that'd be something to make an official goal first, by going through FESCO...
Making Fedora more easily bootstrapable is an important part of Fedora.next and one of the Base Design WG's goals. This could certainly use some more communication, documentation, and development, but I feel pretty confident in saying that it's at least something we're _working on caring about_.
On Tue, Aug 26, 2014 at 3:32 AM, Vít Ondruch vondruch@redhat.com wrote:
Hi,
Recently I have noticed that systemd package dependency is creeping into some packages where it is not necessary. subversion [1] or rsync [2] are good examples. Please consider moving daemon parts into independent subpackages. When I install rsync/subversion, I am typically interested just in client side.
Just to be clear, systemd-libs is in minimal build root already, so I am not complaining about systemd-libs package, but about systemd package.
Sorry for the late response, I've been busy.
I've some interest because I've been backporting current Subversion versions to RHEL 6 over at https://github.com/nkadel/, and trying to get them into repoforge. They won't go in EPEL or mainline RHEL due to significant incompatibilities with the published releases. But consistency with Fedora is useful, so I'm interested.
The problem for subversion is the 'svnserve' daemon, which can be used as a standalone daemon. That should, ideally, be factored into a 'subversion-svnserve-daemon' or similar package. The svnserve daemon is also used for Subversion server side 'svn+ssh' access, so it shouldn't be stripped out completely, but can work as s standalone daemon and needs init scripts or systemd setups for precisely that use. The confusion will occur when people expect to find the daemon in the base 'subversion' package. With frequent new Fedora upgrades, I think it's a great idea to segregate out now as part of the next Fedora release.
Rsync has similar issues for 'rsyncd' as a standalone daemon, which I see have been resolved as an 'rsync-daemon' separate package.
-
Chris Adams -
Daniel J Walsh -
DJ Delorie -
Jan Zelený -
Josh Boyer -
Josh Boyer -
José Abílio Matos -
Lennart Poettering -
Marcela Mašláňová -
Matthew Miller -
Michal Sekletar -
Nico Kadel-Garcia -
Orion Poplawski -
Peter Robinson -
Petr Pisar -
Phil Knirsch -
Rich Mattes -
Stephen John Smoogen -
Till Maas -
Tomasz Torcz -
Vít Ondruch -
Yaakov Selkowitz -
Zbigniew Jędrzejewski-Szmek