On Sunday 12 May 2013 11:01:00 Andrea Turrini wrote:

On 05/12/2013 10:37 AM, ErwinL wrote:

...

What you want to do doesn't work because the "Age" parameter is ignored with the "R" option. See "man tmpfiles.d" for details.

Oops, I have not noted this case. I really would like to know the rational behind this choice, since I find it very weird.

...

Have a look at the file "/usr/lib/tmpfiles.d/tmp.conf". I think that you get what you want if you comment out the two lines starting with an "X". But then I have to take care of it on each update of systemd.

So, the question now is: how can I remove directories older than 3 days? Or, in general, how can I override an "X" in a system provided file?

Andrea, The man page of tmpfiles.d states that files in /etc/tmpfiles.d have precedence over files in /usr/lib/tmpfiles.d. So, it should be sufficient to copy file /usr/lib/tmpfiles.d/tmp.conf to /etc/tmpfiles.d/tmp.conf and edit the copy. Please, read that man page. Erwin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/12/2013 11:28 AM, Andrey Borzenkov wrote:

В Sun, 12 May 2013 11:01:00 +0200 Andrea Turrini пишет:

...

On 05/12/2013 10:37 AM, ErwinL wrote:

...

What you want to do doesn't work because the "Age" parameter is ignored with the "R" option. See "man tmpfiles.d" for details.

Oops, I have not noted this case. I really would like to know the rational behind this choice, since I find it very weird.

Do you have use case for it? "Very weird" is very weak argument.

This topic is the use case: how can I remove specific directories inside /tmp after 3 days while keeping the 10 days /tmp general cleaning? BTW, if I change date to test the effect of copying and adapting tmp.conf, I note the following: Via bios, I have advanced the hardware clock of 1 month, so I performed the test on Jun 12. After the boot, /tmp still contained files created on May. For instance: -rw------- 1 ori users 8350 May 12 12:01 clementine-art-Qq1103.jpg -rw------- 1 ori users 8350 May 10 23:15 clementine-art-Rd1185.jpg -rw------- 1 ori users 2897 May 11 23:52 clementine-art-rS1130.jpg -rw------- 1 ori users 2897 Jun 12 12:18 clementine-art-SO1125.jpg or srwxr-xr-x 1 ori users 0 Jun 12 12:09 qtsingleapp-homeor-67d0-3e8= -rw-r--r-- 1 ori users 0 May 2 12:31 qtsingleapp-homeor-67d0-3e8-lockfile -rw-r--r-- 1 ori users 0 May 2 20:50 qtsingleapp-smplay-ca73-3e8-lockfile How can this be possible? The only possibility is that the cleanup is not executed at boot, but eventually during the uptime (for sure not within 10 minutes from the boot, the time I waited before rebooting and changing bios time). But this leads to: is it safe to remove /tmp/systemd-private-* via R /tmp/systemd-private-* or may this lead to problems? Moreover, the current status is: ori@orodruin:~> cat /etc/tmpfiles.d/tmp.conf # Clear tmp directories separately, to make them easier to override d /tmp 1777 root root 2d d /var/tmp 1777 root root 30d so, how is it possible that /tmp still contains the empty directory: drwx------ 2 ori users 4096 Apr 28 08:47 gpg-sKcjuY/

...

Or, in general, how can I override an "X" in a system provided file?

Copy file under /etc/tmpfiles.d and edit it. This is also documented in man tmpfiles.d

But the manpage does not document my other question, that you have removed from your quote. Moreover, can someone explain me the rationale of the following construction: d /tmp 1777 root root 2d where, by the manpage, d: Create a directory if it doesn't exist yet D: Create or empty a directory So, by using d, one is allowed to expect that the directory is created if missing, and nothing is done if the directory is already there. Otherwise, what is the difference between d and D? Then there is the Age field: The date field, when set, is used to decide what files to delete when cleaning. If a file or directory is older than the current time minus the age field it is deleted. So, how can this be related to a d, that just creates a directory if not existing? Since the age has meaning, as written, for cleaning operation, I would expect this to be related to an r or R operation (and to some extend also D), not to a d. You may point to: "The age field only applies to lines starting with d, D and x. If omitted or set to - no automatic clean-up is done." but still how can you infer that files are removed when you use a d? If original file uses a D, I would agree that this makes sense, since D empties the directory, if existing, so an age may have the following meaning: Create a directory or empty it (limited to content older than age). Now I try to use the following orodruin:~ # cat /etc/tmpfiles.d/tmp.conf # Clear tmp directories separately, to make them easier to override d /tmp 1777 root root 10d d /var/tmp 1777 root root 30d x /tmp/systemd-private-* - - - 2d x /var/tmp/systemd-private-* - - - 2d and see whether I obtain the wanted behavior. Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/12/2013 03:06 PM, Anton Aylward wrote:

Andrea Turrini said the following on 05/12/2013 08:19 AM:

...

This topic is the use case: how can I remove specific directories inside /tmp after 3 days while keeping the 10 days /tmp general cleaning?

Stated like that it is inadequate.

* Three days after what?

After the creation time, or whatever is used for comparing with the age.

* Why? Are they taking up needed space?

They are filling /tmp thus making more difficult to visually look for files in /tmp. And I do not see why if they are not taking up needed space, then this should not be a problem. Are you saying that since they do not take up needed space, then it is OK to let them to fill [/var]/tmp without bounds?

* What if they are still in use or still needed by some active process or process that will become active periodically?

If I know this can not happen, then this is not a problem. If I am not sure, I can change the age or keep the dirs there. BTW, this argument affects also the current system provided files wrt content (if any) of such directories: since X /tmp/systemd-private-* and from the manpage: X: Ignore a path during cleanup. Use this type to prevent path removal as controlled with the Age parameter. Note that if path is a directory, content of a directory is not excluded from clean-up, only directory itself. Lines of this type accept shell-style globs in place of normal path names. Can you ensure that everything is OK if the content is still in use or still needed by some active process or process that will become active periodically? Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sunday 12 May 2013, Anton Aylward wrote:

Andrea Turrini said the following on 05/12/2013 09:42 AM:

...

On 05/12/2013 03:06 PM, Anton Aylward wrote:

...

Andrea Turrini said the following on 05/12/2013 08:19 AM:

...

This topic is the use case: how can I remove specific directories inside /tmp after 3 days while keeping the 10 days /tmp general cleaning?

Stated like that it is inadequate.

* Three days after what?

After the creation time, or whatever is used for comparing with the age.

DANGER WILL ROBINSON! DANGER!

Go though the rest of the file system and look at directories that were CREATED many days ago that contain newly created files or at least files that were created long after the directories or the parent directory of those directories were.

We were talking about empty directories, right? Empty directories do not contain newly created files. BTW I'm sure that even systemd is smart enogugh to delete old files first, And then directories only if they are too old AND EMPTY.

...

...

* Why? Are they taking up needed space?

They are filling /tmp thus making more difficult to visually look for files in /tmp. And I do not see why if they are not taking up needed space, then this should not be a problem. Are you saying that since they do not take up needed space, then it is OK to let them to fill [/var]/tmp without bounds?

First, what's this 'without bounds'?

Second, are they really taking up space? Try running 'df' and see if your /tmp is critical.

it sounds like this is an aesthetic argument, which is really unanswerable.

If space would be the ONLY reason to delete anything then we should clean up dependent on disk usage instead of times only. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrea Turrini said the following on 05/12/2013 11:13 AM:

...

Second, are they really taking up space? Try running 'df' and see if your /tmp is critical.

Each directory uses at least 4k, so they are taking space.

Geez! The litter I have from printing a file is about 10 times that!

...

it sounds like this is an aesthetic argument, which is really unanswerable.

I see other 'junk' created in my /tmp from things like ssh, adobe, various caches, ssh and gpg, plugins to thunderbird, PPD files from CUPS (LOTS! of them!), email attachment files I've viewed, and more. All these are more significant than empty directories.

But they are removed automatically after 10 days.

And in about 10 days you're going to get an update to systemd. Hopefully. Depending on how conservative the packagers are. Lets see: we're on 195 now. That was ... [systemd-devel] [ANNOUNCE] systemd 195 Lennart Poettering lennart at poettering.net Mon Oct 22 17:56:14 PDT 2012 Oct Nov Dec Jan Feb Mar Apr so reckon on openSuse conservative stance introducing a lag of 4-6 months. Sorry, that make it more than 10 days ....

...

Well, what about /var/spool/postfix? Under ./defer and ./deferred there are many directories and hopefully they are empty. Are you going to add those to your list of directories to delete? Why not? Oh, right, its not an aesthetic issue.

Is /var/spool/postfix expected to be cleaned automatically? No

Yes, but you have 10 such empty directories (each taking up at least 4k, maybe more) in at least 2, maybe more, directories, on the same file system as /var/tmp! The issue isn't about whether its expected to be cleaned automatically or not. its that its there and that its taking up space. So we get back to the aesthetics issue ...

Are /tmp/systemd-private-* expected to be cleaned automatically? Yes, since /tmp was expected by upstream to be a tmpfs.

And you are quite capable of running systemctl mask to restore that. Once again openSuse is being conservative by having the default behave the old way, /tmp being on disk, rather than the 'new' way of making it a tmpfs. You want the latest, the most bleeding edge, then don't use openSuse. Either that or make use of the build service and build your own.

...

Personally I think you're making a big issue of something that is going to go away anyway.

Ah, just wait and then no one is allowed to complain.

Complain about a real issue then, like "opensuse is too conservative and isn't moving upstream changes into the updates fast enough for me". Because that's the real issue here. See http://lists.freedesktop.org/archives/systemd-devel/2013-March/009933.html Note the date on that - MARCH 26th. <quote> CHANGES WITH 199: * [...] * Behaviour of PrivateTmp=, ReadWriteDirectories=, ReadOnlyDirectories= and InaccessibleDirectories= has changed. The private /tmp and /var/tmp directories are now shared by all processes of a service (which means ExecStartPre= may now leave data in /tmp that ExecStart= of the same service can still access). When a service is stopped its temporary directories are immediately deleted (normal clean-up with tmpfiles is still done in addition to this though). </quote> Note that - "When a service is stopped its temporary directories are immediately deleted" So complain, yes, but complain about the right thing, which is that openSuse is too conservative for YOUR tastes. Oh, and BTW - there's the list to subscribe to :-) What puzzles me is this. All that 'research' took just a few tries at googling. The cut-and-paste took longer. How come no-one else looked that up? Its not as if there's any PhD level smarts involved in me doing a google search. Now let me ask another question. Has anyone used the build service to build a v199 of systemd? If the answer to that is "yes" then Andrea can add that repository and update systemd and LO! the problem is fixed. -- I suspect that, over time, all bureaucratic processes decay into cargo cults unless regularly challenged by a hostile reality. - Alan Rocker, 23-Nov-2011 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrea Turrini said the following on 05/12/2013 01:29 PM:

...

...

Depending on how conservative the packagers are. I do not think. Why do you still have systemd-44 in your oS 12.2? It should be 195, according to your approach.

I don't follow your logic; The 12.2 system updates from the 12.2 repositories and the 12.3 updates from the 12.3 repositories. Why should the 12.2 update from the 12.3 repository? Again ... # zypper info systemd Information for package systemd: Repository: openSUSE-12.2-Update Name: systemd Version: 44-10.8.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date See: a 12.2 repository and it is up to date. 12.2 is not 12.3 I can't see how it should be 195 - that the most recent in the 12.3 update. Update repositories of 12.2 doesn't mean "update to 12.3". -- "The man who does not read good books has no advantage over the man who can't read them." --Mark Twain -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrea Turrini said the following on 05/12/2013 01:29 PM:

On 05/12/2013 06:19 PM, Anton Aylward wrote:

...

Andrea Turrini said the following on 05/12/2013 11:13 AM:

...

...

Second, are they really taking up space? Try running 'df' and see if your /tmp is critical.

Each directory uses at least 4k, so they are taking space.

Geez! The litter I have from printing a file is about 10 times that!

You asked whether such directories are taking space. And they do. Few space, but they do. Period.

Compared to the transient things in /tmp and /var/tmp and the empty directories elsewhere in /var these are insignificant. I think you have your priorities very, very confused.

...

...

Is /var/spool/postfix expected to be cleaned automatically? No

Yes, but you have 10 such empty directories (each taking up at least 4k, maybe more) in at least 2, maybe more, directories, on the same file system as /var/tmp!

Not related argument.

... because its not about space, is it, its about aesthetics.

...

The issue isn't about whether its expected to be cleaned automatically or not. its that its there and that its taking up space.

So we get back to the aesthetics issue ...

Wrong. The problem is about whether such directories are expected to be cleaned automatically. And they are, since the relative bug [0] has been fixed upstream by removing such directories when no more needed; it is your argument about taking up space.

You want to have it both ways then. So install the fix that Cristian pointed out to you.

...

And you are quite capable of running systemctl mask to restore that.

No, because it is a bug of systemd-195, only hidden by having /tmp mounted as tmpfs. It is just a workaround that may affect overall system behavior.

You really really really do want it both ways.

...

Once again openSuse is being conservative by having the default behave the old way, /tmp being on disk, rather than the 'new' way of making it a tmpfs. You want the latest, the most bleeding edge, then don't use openSuse. Either that or make use of the build service and build your own.

I wonder from where you derived that I want the latest, the most bleeding edge. For sure this is not my case.

Let me get this right: you're saying you want it fixed but you don't actually want to make the changes that will fix it. OBTW: since that capability wasn't in the v44 on my 12.2 system I don't have that aesthetic problem with them littering /tmp on 12.2 box. So if you don't want the latest - which is 12.3, then there's a solution for you. Or do you want it both ways still?

I do not want the latest, the most bleeding. Otherwise I would use factory or at least tumbleweed, but I am using an ordinary oS 12.3 as base system. I use non-official updates only for stuff that does not affect the core functionality of the system and that can be easily rolled back.

Which is the case for both the solutions that Cristian has proposed.

JFYI, I installed oS 12.3 only Apr. 21, while it was released on Mar. 13, so more than 1 month after the release.

Your point being? If you are doing the updates with zypper or yast, to keep up to date then it doesn't matter if you installed it on March 15 or May 10th. A "zypper up" updates to whatever is in the current update repository. For 12.3 that is Repository: openSUSE-12.3-Update Name: systemd Version: 195-13.25.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date Or are you telling us that you don't do an update with zypper or yast?

...

So complain, yes, but complain about the right thing, which is that openSuse is too conservative for YOUR tastes.

Again, I do not want bleeding edge things, so openSUSE is *NOT* too conservative for my tastes.

You really really really really do want it both ways. You want it fixed but aren't willing to update to the 'edge' where it *IS* fixed.

...

Has anyone used the build service to build a v199 of systemd? If the answer to that is "yes" then Andrea can add that repository and update systemd and LO! the problem is fixed.

No, I will not install a non-official update for a core element as systemd, with the risk of being forced to use a rescue system to fix it.

Oh right; and all of openSuse is not SLED so its not official, its all done by volunteers ... -- "Amberley excelled at chess -- one mark, Watson, of a scheming mind." -- Sherlock Holmes, in "The Adventure of the Retired Colourman" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Andrea Turrini said the following on 05/12/2013 02:37 PM:

How do I remove only directories older than 3 days (while keeping the usual 10 days /tmp cleaning)?

Easy. Forget all that fiddling with the config you have been doing and implement either one of the changes Cristian has suggested. -- For the time will come when men will not put up with sound doctrine. Instead, to suit their own desires, they will gather around them a great number of teachers to say what their itching ears want to hear. - II Timothy 4:3 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 12/05/13 14:01, Andrey Borzenkov escribió:

В Sun, 12 May 2013 17:13:48 +0200 Andrea Turrini пишет:

...

Each boot/service start adds a new directory

That simply not true.

You are making storm in a teacup.

In my machine TWO of the default services use PrivateTmp, so indeed, it is not that each boot/service adds a new directory. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2013-05-12 at 09:06 -0400, Anton Aylward wrote:

* What if they are still in use or still needed by some active process or process that will become active periodically?

Well, as it is systemd who creates and deletes those directories, it also knows if they are in use and can be deleted or not :-) - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlGQQ7EACgkQtTMYHG2NR9WrJgCeJl01Sj2i6W6HPRudRlnKBEPD XTYAnjwlGAPJ6KRhmq9g+Uzn/MpuHxwV =0rBm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/12/2013 01:31 PM, Anton Aylward wrote:

Andrea Turrini said the following on 05/12/2013 03:17 AM:

...

So, the question is: how do I remove only directories older than 3 days? Or is this a bug?

I'm not sure this is a good idea.

First, the "R" for remove on boot is as Andrey points out a better idea since a machine might be up for 3 days or more (even if your normal strategy is daily boot).

See my other email: can you ensure that the cleaning is performed at boot? There are behaviors that seem to show that this is not the case.

Second, this is really all a non issue. As Cristian points out, systemd is a work in progress and this is an artefact of one revision and will go away with the next release from upstream.

And will this next release land in oS 12.3 as official update? Can you ensure this?

One reason I also run Fedora is "to see what's coming..."

If this is the only Linux list you subscribe to then you're going to have a very limited view of what's going on.

I have a view of what is going on relative to what I use, openSUSE, not Fedora. Or should one be subscribed to every distribution/upstream project to see what is going on? Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/12/2013 03:02 PM, Anton Aylward wrote:

Andrea Turrini said the following on 05/12/2013 08:25 AM:

...

And will this next release land in oS 12.3 as official update? Can you ensure this?

I'm unclear what you're asking.

It is simple: will there be an official update (i.e., a package in openSUSE-12.3-Update repository) for systemd that prevents/solves the current status, i.e., the creation without removal of these [/var]/tmp/systemd-private-* directories? Or in other words, if this problem has been solved by systemd-N with N strictly greater than 195, will systemd-195 be replaced by systemd-N via an official update or will changes in systemd-N be backported to systemd-195 via an official update? My impression is that the current status will stand until oS 12.3 goes out of support, and then no one will care about the problem.

One 12.2 I have (according to zypper info)

Repository: openSUSE-12.2-Update Name: systemd Version: 44-10.8.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date

and on 12.3

Repository: openSUSE-12.3-Update Name: systemd Version: 195-13.25.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date

WOW! What a difference!

So? they are just numbers; nothing prevents the version to be increased by 1 just for fixing a typo.

And please note that I ma using the update repositories.

Me too, but I just see: ori@orodruin:~> zypper se -s --match-exact systemd Verbosity: 2 Non-option program arguments: 'systemd' Initializing Target Loading repository data... Reading installed packages... Force resolution: No S | Name | Type | Version | Arch | Repository --+---------+------------+-------------+--------+--------------------- i | systemd | package | 195-13.25.1 | x86_64 | openSUSE-12.3-Update v | systemd | package | 195-13.18.1 | x86_64 | openSUSE-12.3-Update v | systemd | package | 195-13.14.1 | x86_64 | openSUSE-12.3-Update v | systemd | package | 195-13.11.1 | x86_64 | openSUSE-12.3-Oss v | systemd | package | 195-13.25.1 | i586 | openSUSE-12.3-Update v | systemd | package | 195-13.18.1 | i586 | openSUSE-12.3-Update v | systemd | package | 195-13.14.1 | i586 | openSUSE-12.3-Update v | systemd | package | 195-13.11.1 | i586 | openSUSE-12.3-Oss | systemd | srcpackage | 195-13.25.1 | noarch | openSUSE-12.3-Update | systemd | srcpackage | 195-13.18.1 | noarch | openSUSE-12.3-Update | systemd | srcpackage | 195-13.14.1 | noarch | openSUSE-12.3-Update

Perhaps Cristian can tell up more about what's going on 'upstream',

Why should I care about upstream if problems are downstream? If I would report this problem upstream, probably it will be closed as INVALID since it seems that they have already fixed it in a later version, or because downstream is using a different setup not supported by upstream ([/var]/tmp on disk instead of on RAM), but such version will not be made available officially for oS 12.3.

This is a very general list for Suse; there are specific ones for things like the kernel and other areas of development; specific ones like factory, kde, gnome ... See https://en.opensuse.org/openSUSE:Mailing_lists

Currently I am subscribed to this, factory, translation, kde, project, and possibly some other. Since I do not see an opensuse-systemd list, and we are talking about oS 12.3 and not factory, opensuse is the only list that is OK for this discussion (except for opensuse-offtopic, but this is not an offtopic). Or am I missing the correct list? Best, Andrea -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/12/2013 04:58 PM, Anton Aylward wrote:

Andrea Turrini said the following on 05/12/2013 10:20 AM:

...

Since I do not see an opensuse-systemd list, and we are talking about oS 12.3 and not factory, opensuse is the only list that is OK for this discussion (except for opensuse-offtopic, but this is not an offtopic). Or am I missing the correct list?

Dunno.

I just googled for "systemd mailing list" but then I'm one of those people whose first recourse to almost eveything is to google for it.

And? If I open a topic similar to this one in one of these ml, I already know the answer I receive: This is not a list for openSUSE problems, ask in openSUSE lists; or Upgrade to 199 or later [0]. Best, Andrea [0] http://lists.opensuse.org/opensuse/2013-05/msg00145.html -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 12/05/13 10:20, Andrea Turrini escribió:

It is simple: will there be an official update (i.e., a package in openSUSE-12.3-Update repository) for systemd that prevents/solves the current status, i.e., the creation without removal of these [/var]/tmp/systemd-private-* directories?

If you can make your case, in bugzilla on why we should fix a cosmetic problem (the directories take next to nothing of resources on the system)

Or in other words, if this problem has been solved by systemd-N with N strictly greater than 195, will systemd-195 be replaced by systemd-N via an official update or will changes in systemd-N be backported to systemd-195 via an official update?

My impression is that the current status will stand until oS 12.3 goes out of support, and then no one will care about the problem.

...

One 12.2 I have (according to zypper info)

Repository: openSUSE-12.2-Update Name: systemd Version: 44-10.8.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date

and on 12.3

Repository: openSUSE-12.3-Update Name: systemd Version: 195-13.25.1 Arch: i586 Vendor: openSUSE Installed: Yes Status: up-to-date

WOW! What a difference!

So? they are just numbers; nothing prevents the version to be increased by 1 just for fixing a typo.

THe version number increased after udev was merged into systemd, the udev version number took over the systemd one. The versions shipped are not randomly choosen, the are "distribution release points" (to give it a name) , where distributions can settle in. The next "distribution point" is systemd 204/205 (or whatever version is pre-kdbus [1]) after that a new bulk of invasive changes will take place, on which systemd will require new kernel releases/features. [1] https://github.com/gregkh/kdbus/blob/master/kdbus.txt -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org