systemd dependencies

[Vít Ondruch]

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

[Michal Sekletar]

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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Vít Ondruch]

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

[Michal Sekletar]

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.

>  
>  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. 
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.

>  
>  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). 
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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Lennart Poettering]

On Tue, 26.08.14 12:59, Vít Ondruch (vondruch(a)redhat.com) wrote:

>  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). 
Why? 

I am really against splitting things up into a million of subpackages,
unless you have a ver good reason for a split.

Lennart

-- 
Lennart Poettering, Red Hat

[Vít Ondruch]

Dne 26.8.2014 13:51, Lennart Poettering napsal(a):
>  On Tue, 26.08.14 12:59, Vít Ondruch (vondruch(a)redhat.com) wrote:
>
> > 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).
>  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

[Lennart Poettering]

On Tue, 26.08.14 14:22, Vít Ondruch (vondruch(a)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

-- 
Lennart Poettering, Red Hat

[DJ Delorie]

>  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?

[Rich Mattes]

On Tue, Aug 26, 2014 at 10:46 AM, DJ Delorie <dj(a)redhat.com&gt; 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_owne...

[Chris Adams]

Once upon a time, DJ Delorie <dj(a)redhat.com&gt; 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?).

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 26, 2014 at 10:16:46AM -0500, Chris Adams wrote:
>  Once upon a time, DJ Delorie <dj(a)redhat.com&gt; 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

[Tomasz Torcz]

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?

-- 
Tomasz Torcz                "Funeral in the morning, IDE hacking
xmpp: zdzichubg(a)chrome.pl    in the afternoon and evening." - Alan Cox

[Zbigniew Jędrzejewski-Szmek]

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"

[Till Maas]

On Tue, Aug 26, 2014 at 12:59:23PM +0200, Vít Ondruch wrote:

>  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). 
The directories can probably just be added to the filesystem package.
Opening a bugzilla ticket usually helps here.

Regards
Till

[Orion Poplawski]

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:
>
>  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. 
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


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: [phone]
3380 Mitchell Lane                       orion(a)nwra.com
Boulder, CO 80301                   http://www.nwra.com

[Vít Ondruch]

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:
> >
> > 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.
>
>  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

[Orion Poplawski]

On 08/26/2014 04:59 AM, Vít Ondruch wrote:
>  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). 
It's not (just) filesystem ownership, it's scriptlet processing:

https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Macroized_scri...

so you need systemctl

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: [phone]
3380 Mitchell Lane                       orion(a)nwra.com
Boulder, CO 80301                   http://www.nwra.com

[Lennart Poettering]

On Tue, 26.08.14 11:06, Michal Sekletar (msekleta(a)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

-- 
Lennart Poettering, Red Hat

[Lennart Poettering]

On Tue, 26.08.14 09:32, Vít Ondruch (vondruch(a)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

-- 
Lennart Poettering, Red Hat

[Vít Ondruch]

Dne 26.8.2014 13:49, Lennart Poettering napsal(a):
>  On Tue, 26.08.14 09:32, Vít Ondruch (vondruch(a)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

[Lennart Poettering]

On Tue, 26.08.14 14:18, Vít Ondruch (vondruch(a)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

-- 
Lennart Poettering, Red Hat

[Vít Ondruch]

Dne 26.8.2014 14:23, Lennart Poettering napsal(a):
>  On Tue, 26.08.14 14:18, Vít Ondruch (vondruch(a)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/...:
[Errno 14] HTTP Error 404 - Not Found
Trying other mirror.
http://less.cogeco.net/fedora/linux/development/rawhide/i386/os/Packages/...:
[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

[Vít Ondruch]

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(a)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/...:
>  [Errno 14] HTTP Error 404 - Not Found
>  Trying other mirror.
>
> http://less.cogeco.net/fedora/linux/development/rawhide/i386/os/Packages/...:
>  [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

[Jan Zelený]

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(a)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

[Lennart Poettering]

On Tue, 26.08.14 14:55, Vít Ondruch (vondruch(a)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

-- 
Lennart Poettering, Red Hat

[Stephen John Smoogen]

On 26 August 2014 10:43, Lennart Poettering <mzerqung(a)0pointer.de&gt; wrote:

>  On Tue, 26.08.14 14:55, Vít Ondruch (vondruch(a)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?


-- 
Stephen J Smoogen.

[Chris Adams]

Once upon a time, Stephen John Smoogen <smooge(a)gmail.com&gt; 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.

-- 
Chris Adams <linux(a)cmadams.net&gt;

[Josh Boyer]

On Tue, Aug 26, 2014 at 1:38 PM, Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Stephen John Smoogen <smooge(a)gmail.com&gt;
> 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

[Chris Adams]

Once upon a time, Josh Boyer <jwboyer(a)gmail.com&gt; 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".
-- 
Chris Adams <linux(a)cmadams.net&gt;

[Josh Boyer]

On Tue, Aug 26, 2014 at 1:56 PM, Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Josh Boyer <jwboyer(a)gmail.com&gt; 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

[José Abílio Matos]

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?

-- 
José Abílio

[Petr Pisar]

On 2014-08-26, José Matos <jamatos(a)fc.up.pt&gt; 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

[Vít Ondruch]

Dne 26.8.2014 18:43, Lennart Poettering napsal(a):
>  On Tue, 26.08.14 14:55, Vít Ondruch (vondruch(a)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


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1134065

[Daniel J Walsh]

On 08/26/2014 08:23 AM, Lennart Poettering wrote:
>  On Tue, 26.08.14 14:18, Vít Ondruch (vondruch(a)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.

[DJ Delorie]

>  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.

[Josh Boyer]

On Tue, Aug 26, 2014 at 10:44 AM, DJ Delorie <dj(a)redhat.com&gt; 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

[Lennart Poettering]

On Tue, 26.08.14 10:44, DJ Delorie (dj(a)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

-- 
Lennart Poettering, Red Hat

[Peter Robinson]

> > > 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

[Zbigniew Jędrzejewski-Szmek]

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

[Marcela Mašláňová]

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

[Phil Knirsch]

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

-- 
Philipp Knirsch              | Tel.:  [phone]
Manager Core Services        | Fax.:  [phone]
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch(a)redhat.com&gt;
Wankelstrasse 5              | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany

[Yaakov Selkowitz]

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.

-- 
Yaakov Selkowitz
Associate Software Engineer, ARM
Red Hat, Inc.

[Matthew Miller]

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_.


-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Nico Kadel-Garcia]

On Tue, Aug 26, 2014 at 3:32 AM, Vít Ondruch <vondruch(a)redhat.com&gt; 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.