Re: systemd system unit files and UsrMove
Am 20.02.2012 21:19, schrieb Miloslav Trmač: On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers kay.siev...@vrfy.org wrote: /usr/share in our general understanding not to be used for package-private things. Who is we? This is in direct conflict with the FHS: Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose. There is no reason to have /usr/share/pkgdir/ and /usr/lib/pkgdir, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share. Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/execenvfhs.html http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA /usr/lib : Libraries for programming _and_ packages Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. For example, the perl5 subdirectory for Perl 5 modules and libraries. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer harald.ho...@gmail.com wrote: Am 20.02.2012 21:19, schrieb Miloslav Trmač: On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers kay.siev...@vrfy.org wrote: There is no reason to have /usr/share/pkgdir/ and /usr/lib/pkgdir, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share. Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/execenvfhs.html http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA /usr/lib : Libraries for programming _and_ packages Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, There is equivalent language in the /usr/share section, with no indication that the two are supposed to be exclusive. all architecture-dependent data exclusively used by the application must be placed within that subdirectory. Again, equivalent language in the /usr/share section talks about architecture-independent data. When coupled with the front parts of FHS, it's quite clear that the intent is to split the application's data between the two directories. BTW, pedantic reading of FHS seems not to support at all the concept of an application-defined directory into which other applications are supposed to store additional files. That's a pretty unreasonable interpretation, however. (I think there is sort of a good reason not to require doing the lib vs. share split in Fedora - adding one more directory to check is a not a packaging change, it is a semantic change, it would be now necessary to somehow handle the case when lib and share each contain a different file with the same name. In my view, a lot of the interesting udev and systemd really belong to /etc anyway...) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 09:17:30PM +0100, Kay Sievers wrote:
On Mon, Feb 20, 2012 at 20:18, Toshio Kuratomi a.bad...@gmail.com wrote:
On Mon, Feb 20, 2012 at 06:30:11PM +0100, Lennart Poettering wrote:
On Mon, 20.02.12 09:25, Toshio Kuratomi (a.bad...@gmail.com) wrote:
This sounds like the unit files belong in %{_libdir} now? However, that
would mean that they can't go into noarch packages. So we probably need
to
know a little more about just how architecture dependent these unit files
can be.
No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship
two different versions for 32bit and 64bit. We want just one, hence they
belong in /lib unconditionally)
Okay, so this is one more area where when people mispackage a library and
a program in the same subpackage, they'll get bitten?
I'm convinced that the default of $libexedir should just be set to
/usr/lib and all packages using libexecdir should use a subdir in
that,
So I have to admit here that I have no idea why systemd is using $libexecdir
here. The definition of libexecdir does not support the storing of
unit files:
libexecdir
The directory for installing executable programs to be run by other
programs rather than by users. This directory should normally be
‘/usr/local/libexec’, but write it as ‘$(exec_prefix)/libexec’. (If you are
using Autoconf, write it as ‘@libexecdir@’.)
The definition of ‘libexecdir’ is the same for all packages, so you should
install your data in a subdirectory thereof. Most packages install their
data under ‘$(libexecdir)/package-name/’, possibly within additional
subdirectories thereof, such as
‘$(libexecdir)/package-name/machine/version’.
unit files are declarative, not executable. It sounds like upstream systemd
wants to use $(exec_prefix)/lib/systemd for the unit files and is attempting
to shoehorn those into libexecdir because some distros set libexecdir to
${exec_prefix}/lib whereas some distros on some arches set libdir to
${exec_prefix}lib64 This is incorrect use of libexecdir. They should just
use ${exec_prefix}/lib if that is the place that makes the most sense.
(Or make up a new config variable that they submit to the GNU coding
standards).
-Toshio
pgpP55HiwNJTI.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Am 21.02.12 14:37, schrieb Miloslav Trmač: On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer harald.ho...@gmail.com wrote: Am 20.02.2012 21:19, schrieb Miloslav Trmač: On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers kay.siev...@vrfy.org wrote: There is no reason to have /usr/share/pkgdir/ and /usr/lib/pkgdir, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share. Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/execenvfhs.html http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA /usr/lib : Libraries for programming _and_ packages Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, There is equivalent language in the /usr/share section, with no indication that the two are supposed to be exclusive. all architecture-dependent data exclusively used by the application must be placed within that subdirectory. Again, equivalent language in the /usr/share section talks about architecture-independent data. When coupled with the front parts of FHS, it's quite clear that the intent is to split the application's data between the two directories. BTW, pedantic reading of FHS seems not to support at all the concept of an application-defined directory into which other applications are supposed to store additional files. That's a pretty unreasonable interpretation, however. (I think there is sort of a good reason not to require doing the lib vs. share split in Fedora - adding one more directory to check is a not a packaging change, it is a semantic change, it would be now necessary to somehow handle the case when lib and share each contain a different file with the same name. In my view, a lot of the interesting udev and systemd really belong to /etc anyway...) Mirek Well, as recently stated on the FHS mailing list, the FHS just documents common practice and does not set new standards. So, if we want a new standard in the FHS, we will have to invent, document and ship it. Same thing was happening when Red Hat/Fedora started with /usr/libexec and /run. It's now documented, even though only RH/Fedora uses /usr/libexec. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Wed, Feb 22, 2012 at 7:46 AM, Harald Hoyer harald.ho...@gmail.com wrote: Am 21.02.12 14:37, schrieb Miloslav Trmač: On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer harald.ho...@gmail.com wrote: Am 20.02.2012 21:19, schrieb Miloslav Trmač: On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers kay.siev...@vrfy.org wrote: There is no reason to have /usr/share/pkgdir/ and /usr/lib/pkgdir, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share. Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/execenvfhs.html http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA /usr/lib : Libraries for programming _and_ packages Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, There is equivalent language in the /usr/share section, with no indication that the two are supposed to be exclusive. all architecture-dependent data exclusively used by the application must be placed within that subdirectory. Again, equivalent language in the /usr/share section talks about architecture-independent data. When coupled with the front parts of FHS, it's quite clear that the intent is to split the application's data between the two directories. snipped Well, as recently stated on the FHS mailing list, the FHS just documents common practice and does not set new standards. So, if we want a new standard in the FHS, we will have to invent, document and ship it. *shrug* What I really care about in this discussion is that incorrect claims that LSB/FHS mandates/allows something don't become accepted as general knowledge. Recently there have been rather many instances of X is the standard and you need to follow it to stay compatible when X were way too new to be considered a standard. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Fri, 17.02.12 10:46, Nathaniel McCallum (nathan...@natemccallum.com) wrote: I'm a fan of systemd [1]. And although I didn't like the fact that unit files were stored in /lib, I understood the rationale since there was no /share. However, I've just recently discovered [2] that after UsrMove unit files will be stored in /usr/lib. Can we not do better than this? And I'd really rather not work around the problem [3]. Seriously, please don't do this. The unit files are in /lib for a couple of reasons. Firstly, before the /usr merge there was no /share, so we had to place them in /lib. Secondly I think that /lib is actually the better fit for them, simply because I consider them closely related to the code they wrap, and code belongs in lib, libexec or bin. How does that matter? Well, the unit files are very often dependendent on/closely related to the architecture, and make little sense to share them between archs. This applies to a couple of units we ship with systemd itself (for example the hugepages mount unit), but even more often to unit we don't ship ourselves (think mcelog). And distributing these unit files among a number of dirs would seriously suck. We need to retain compatibility for the directory from before the /usr merge and I think lib/ is actually a better place for this than share/, hence I think I see little reason to move this. /share is a great place for truly arch independent data that is shared between multiple applications, and which is read by multiple applications (such as icons, man pages, dictionaries and suchlike). But for stuff that is very close to specific bits of code, and is only read by a single tool /lib is the much better place I think. A good way to think about this is maybe if I remove something in /lib it seriously impacts the control flow of code vs. if I remove something in /share it hast little impact on control flow. Something similar applies to udev rules and similar almost code bits. But yeah, I know people will disagree with us on this. Maybe a different way to think about this is to think about shell scripts. We ship those in /bin, and not in /share either. And it is good that way. And if that still doesn't convince you, then I hope at least the keep compat issue pointed out above matters enough to you. So, no plans to move the unit files to /usr/share. Sorry. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Lun 20 février 2012 13:02, Lennart Poettering a écrit : Something similar applies to udev rules and similar almost code bits. But yeah, I know people will disagree with us on this. Lennart , you realise, do you, that people are unlikely to fix the historical exceptions they've benefited from as part of systemd or usrmove if you're championing the creation of new exceptions for your own sake in parallel. Systemd unit files are no more cody and app-specific (and in fact quite a lot less) than emacs lisp files or java jar files or docbook xslt processing rules or a lot more stuff I'm forgetting about right now and those have been in /usr/share for a *long* time. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: Le Lun 20 février 2012 13:02, Lennart Poettering a écrit : Something similar applies to udev rules and similar almost code bits. But yeah, I know people will disagree with us on this. Lennart , you realise, do you, that people are unlikely to fix the historical exceptions they've benefited from as part of systemd or usrmove if you're championing the creation of new exceptions for your own sake in parallel. This isn't really a new exception for me. There's a ton of files that are not strictly arch dependent in bin, lib, libexec. Shell scripts, Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB symlinks, Java files, Ruby files, yadda yadda yadda. The thing is simply that there are cases where things are clear that they belong on /lib, and others where it is clear that they belong in /share. And then there is this huge grey area in the middle of those files where things aren't super clear. The line between /lib and /share is blurry. And since about always people then ended up coming to different conclusions and hence dropped some stuff that you don't think belongs in /lib into that very dir, and some stuff that others don't think belongs in /share into that very dir. I think a rule of if in doubt, /lib is preferable is the safe choice here though. In the case for unit files we have a couple of good reasons to consider them arch-specific enough beyond just mere if in doubt. (see my earlier mail for them). Systemd unit files are no more cody and app-specific (and in fact quite a lot less) than emacs lisp files or java jar files or docbook xslt processing rules or a lot more stuff I'm forgetting about right now and those have been in /usr/share for a *long* time. I see a ton of jar files in /usr/lib here actually. The world isn't black and white. The separation between /share and /lib is more complex than simple binary logic. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 13:51, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 20.02.12 13:32, Nicolas Mailhot (nicolas.mail...@laposte.net) wrote: Le Lun 20 février 2012 13:02, Lennart Poettering a écrit : Something similar applies to udev rules and similar almost code bits. But yeah, I know people will disagree with us on this. Lennart , you realise, do you, that people are unlikely to fix the historical exceptions they've benefited from as part of systemd or usrmove if you're championing the creation of new exceptions for your own sake in parallel. It's not a new exception, it's the reality for udev since ~6 years. This isn't really a new exception for me. There's a ton of files that are not strictly arch dependent in bin, lib, libexec. Shell scripts, Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB symlinks, Java files, Ruby files, yadda yadda yadda. The thing is simply that there are cases where things are clear that they belong on /lib, and others where it is clear that they belong in /share. And then there is this huge grey area in the middle of those files where things aren't super clear. The line between /lib and /share is blurry. And since about always people then ended up coming to different conclusions and hence dropped some stuff that you don't think belongs in /lib into that very dir, and some stuff that others don't think belongs in /share into that very dir. I think a rule of if in doubt, /lib is preferable is the safe choice here though. In the case for unit files we have a couple of good reasons to consider them arch-specific enough beyond just mere if in doubt. (see my earlier mail for them). I second that. Systemd unit files are no more cody and app-specific (and in fact quite a lot less) than emacs lisp files or java jar files or docbook xslt processing rules or a lot more stuff I'm forgetting about right now and those have been in /usr/share for a *long* time. I see a ton of jar files in /usr/lib here actually. The world isn't black and white. The separation between /share and /lib is more complex than simple binary logic. That sounds right. And for the same reason, the udev rules need to stay in lib/ and not move to share/. Udev rules are not meant to be *shared* across anything, not across different machines, not across architectures, not across multiple packages. They only get installed _for_ the udev version that is the primary architecture, and there can only be one udev version installed on a system. The rules get installed by multiple packages, sure; but they do not involve any, and must actually prevent any sort of *sharing*. The very same that is true for udev, is true for sytemd units. Rules and units do not provide any additional or optional data, they influence the actual global system runtime behaviour, they change and extend the system, very much like a service plugin or a shared object. That they are actually text file, is an implementation detail that should not have influence on the installation directory. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, 2012-02-20 at 13:51 +0100, Lennart Poettering wrote: This isn't really a new exception for me. There's a ton of files that are not strictly arch dependent in bin, lib, libexec. Shell scripts, Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB symlinks, Java files, Ruby files, yadda yadda yadda. Not that it matters much, but just before somebody gets the wrong ideas: pkg-config files are arch-dependent because of multilib. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 01:02:11PM +0100, Lennart Poettering wrote:
On Fri, 17.02.12 10:46, Nathaniel McCallum (nathan...@natemccallum.com) wrote:
I'm a fan of systemd [1]. And although I didn't like the fact that unit
files were stored in /lib, I understood the rationale since there was no
/share. However, I've just recently discovered [2] that after UsrMove unit
files will be stored in /usr/lib. Can we not do better than this? And I'd
really rather not work around the problem [3].
Seriously, please don't do this.
The unit files are in /lib for a couple of reasons. Firstly, before the
/usr merge there was no /share, so we had to place them in
/lib. Secondly I think that /lib is actually the better fit for them,
simply because I consider them closely related to the code they wrap,
and code belongs in lib, libexec or bin. How does that matter? Well, the
unit files are very often dependendent on/closely related to the
architecture, and make little sense to share them between archs. This
applies to a couple of units we ship with systemd itself (for example
the hugepages mount unit), but even more often to unit we don't ship
ourselves (think mcelog). And distributing these unit files among a
number of dirs would seriously suck.
This sounds like the unit files belong in %{_libdir} now? However, that
would mean that they can't go into noarch packages. So we probably need to
know a little more about just how architecture dependent these unit files
can be.
-Toshio
pgpaq3J20e4fy.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, 20.02.12 09:25, Toshio Kuratomi (a.bad...@gmail.com) wrote:
On Mon, Feb 20, 2012 at 01:02:11PM +0100, Lennart Poettering wrote:
On Fri, 17.02.12 10:46, Nathaniel McCallum (nathan...@natemccallum.com)
wrote:
I'm a fan of systemd [1]. And although I didn't like the fact that unit
files were stored in /lib, I understood the rationale since there was no
/share. However, I've just recently discovered [2] that after UsrMove unit
files will be stored in /usr/lib. Can we not do better than this? And I'd
really rather not work around the problem [3].
Seriously, please don't do this.
The unit files are in /lib for a couple of reasons. Firstly, before the
/usr merge there was no /share, so we had to place them in
/lib. Secondly I think that /lib is actually the better fit for them,
simply because I consider them closely related to the code they wrap,
and code belongs in lib, libexec or bin. How does that matter? Well, the
unit files are very often dependendent on/closely related to the
architecture, and make little sense to share them between archs. This
applies to a couple of units we ship with systemd itself (for example
the hugepages mount unit), but even more often to unit we don't ship
ourselves (think mcelog). And distributing these unit files among a
number of dirs would seriously suck.
This sounds like the unit files belong in %{_libdir} now? However, that
would mean that they can't go into noarch packages. So we probably need to
know a little more about just how architecture dependent these unit files
can be.
No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship
two different versions for 32bit and 64bit. We want just one, hence they
belong in /lib unconditionally)
Best way to specify the path is %{_unitdir} however, which points to the
actual unit dir, and has been updated for the /usr merge already.
Lennart
--
Lennart Poettering - Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Feb 20, 2012 6:25 PM, Toshio Kuratomi a.bad...@gmail.com wrote:
This sounds like the unit files belong in %{_libdir} now? However, that
would mean that they can't go into noarch packages. So we probably need
to
know a little more about just how architecture dependent these unit files
can be.
There is some serious confusion going on here with Fedora and libexec, not
only regarding the lib/ vs share/ problem.
The recommended defaults as mentioned in the packaging guidelines are just
plain wrong. The recent bug we opened regarding this was just closed
wontfix.
Udev rules and systemd units belong to the installed daemon. This daemon
can only exist exactly one single time, and never be installed by multilib
packages, hence they do not ever belong into libdir. We support compat arch
only, not multiarch. Multiarch would look completely different anyway, and
compat arch does not need or want to involve libdir here.
The rules and units belong in 'libexecdir' which is upstream, and by LSB,
called and defined as /usr/lib/pkgname. Putting anything like that into
libdir is just wrong.
What the Fedora guidlines recommend here is not only wrong, it is also
playing bad with upstream, and as mentioned in the bug, I personally
consider it upstream-unfriendly, upstream-ignorant and against all common
sense in reducing the Linux distro balcanization, and just a bad example
how not to package tools today.
Please stop recommending or installing tools or other non shared objects in
libdir, they almost never belong there. I can see that a few exceptions can
be granted here, because it makes it easier to support binaries, that are
actually exclusively and directly bundled with a shared object, but
everything else just does not belong into libdir.
Thanks,
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 06:30:11PM +0100, Lennart Poettering wrote:
On Mon, 20.02.12 09:25, Toshio Kuratomi (a.bad...@gmail.com) wrote:
On Mon, Feb 20, 2012 at 01:02:11PM +0100, Lennart Poettering wrote:
On Fri, 17.02.12 10:46, Nathaniel McCallum (nathan...@natemccallum.com)
wrote:
I'm a fan of systemd [1]. And although I didn't like the fact that unit
files were stored in /lib, I understood the rationale since there was no
/share. However, I've just recently discovered [2] that after UsrMove
unit
files will be stored in /usr/lib. Can we not do better than this? And
I'd
really rather not work around the problem [3].
Seriously, please don't do this.
The unit files are in /lib for a couple of reasons. Firstly, before the
/usr merge there was no /share, so we had to place them in
/lib. Secondly I think that /lib is actually the better fit for them,
simply because I consider them closely related to the code they wrap,
and code belongs in lib, libexec or bin. How does that matter? Well, the
unit files are very often dependendent on/closely related to the
architecture, and make little sense to share them between archs. This
applies to a couple of units we ship with systemd itself (for example
the hugepages mount unit), but even more often to unit we don't ship
ourselves (think mcelog). And distributing these unit files among a
number of dirs would seriously suck.
This sounds like the unit files belong in %{_libdir} now? However, that
would mean that they can't go into noarch packages. So we probably need to
know a little more about just how architecture dependent these unit files
can be.
No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship
two different versions for 32bit and 64bit. We want just one, hence they
belong in /lib unconditionally)
Okay, so this is one more area where when people mispackage a library and
a program in the same subpackage, they'll get bitten?
Fair enough.
-Toshio
pgpxXKeMXVU3E.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Lun 20 février 2012 18:18, Nils Philippsen a écrit : On Mon, 2012-02-20 at 13:51 +0100, Lennart Poettering wrote: This isn't really a new exception for me. There's a ton of files that are not strictly arch dependent in bin, lib, libexec. Shell scripts, Python scripts, udev rules, pkg-config files, a ton of rpm files, LSB symlinks, Java files, Ruby files, yadda yadda yadda. Not that it matters much, but just before somebody gets the wrong ideas: pkg-config files are arch-dependent because of multilib. and the java files are there either because they use jni (so not arch-independant) or are remnants of the time gcj was use to native-compile them (and gcj was dropped before it learnt not to require that .jars and generated native code be in the same dir) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Lun 20 février 2012 18:50, Kay Sievers a écrit : On Feb 20, 2012 6:25 PM, Toshio Kuratomi a.bad...@gmail.com wrote: Udev rules and systemd units belong to the installed daemon. This daemon can only exist exactly one single time, and never be installed by multilib packages, hence they do not ever belong into libdir. Actually, Udev rules and systemd units belong to the package that installed them. That's why hiding them in a private lib dir is wrong When amavisd instaciates clamav using the generic unit shipped with clamav but using an amavisd-specific conf file the clamav systemd unid is shared with amavisd That's why share is the natural place to share this arch-independant configuration and putting it in /usr/lib is grandfathering an exception that only existed because /share didn't exist -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 20:42, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 20 février 2012 18:50, Kay Sievers a écrit : On Feb 20, 2012 6:25 PM, Toshio Kuratomi a.bad...@gmail.com wrote: Udev rules and systemd units belong to the installed daemon. This daemon can only exist exactly one single time, and never be installed by multilib packages, hence they do not ever belong into libdir. Actually, Udev rules and systemd units belong to the package that installed them. That's why hiding them in a private lib dir is wrong When amavisd instaciates clamav using the generic unit shipped with clamav but using an amavisd-specific conf file the clamav systemd unid is shared with amavisd That's why share is the natural place to share this arch-independant configuration and putting it in /usr/lib is grandfathering an exception that only existed because /share didn't exist I couldn't disagree more. /usr/share in our general understanding not to be used for package-private things. There is no reason to have /usr/share/pkgdir/ and /usr/lib/pkgdir, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share. Even the original distinction between arch-dependent and arch-independent to support a share/ subdir that can be *shared* between different machines will break with config like udev and systemd in share/. This is not a *natural* place at all. We tend to interpret /usr/share as something today, to place stuff into that is really *shared* on the same host, like icons, man pages, things that are mere a collection of similar stuff that multiple packages use. It's definitely not a place to store system instructions and system plugins. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 20:18, Toshio Kuratomi a.bad...@gmail.com wrote:
On Mon, Feb 20, 2012 at 06:30:11PM +0100, Lennart Poettering wrote:
On Mon, 20.02.12 09:25, Toshio Kuratomi (a.bad...@gmail.com) wrote:
This sounds like the unit files belong in %{_libdir} now? However, that
would mean that they can't go into noarch packages. So we probably need to
know a little more about just how architecture dependent these unit files
can be.
No, not %{_libdir}, but rather %{_prefix}/lib. (i.e. we do not want to ship
two different versions for 32bit and 64bit. We want just one, hence they
belong in /lib unconditionally)
Okay, so this is one more area where when people mispackage a library and
a program in the same subpackage, they'll get bitten?
I'm convinced that the default of $libexedir should just be set to
/usr/lib and all packages using libexecdir should use a subdir in
that, and $libdir should not be involved at all, this results in
/usr/lib/udev/cdrom_id, and /usr/lib/systemd/systemd-journald and so
on. This is actually what most distributions do today and what we
envision for the future of a cross-distribution unified Linux.
The general rule for $libdir is that it is reserved for shared objects
and their directly associated files like pkgconfig files.
There are valid cases where shared objects exec() their own helpers,
like when elevated privileges and setuid/capabilities are involved,
that can be a good and valid reason to drop the binary in $libdir if
multilib installation with separate callout helpers need to be
supported; but almost all other packages should not mess there.
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers kay.siev...@vrfy.org wrote: /usr/share in our general understanding not to be used for package-private things. Who is we? This is in direct conflict with the FHS: Any program or package which contains or requires data that doesn't need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally). It is recommended that a subdirectory be used in /usr/share for this purpose. There is no reason to have /usr/share/pkgdir/ and /usr/lib/pkgdir, even LSB specifies that only a _single_ dir should be used, hence the one in lib not in share. Chapter and verse, please? AFAICS all LSB says is http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/execenvfhs.html . Even the original distinction between arch-dependent and arch-independent to support a share/ subdir that can be *shared* between different machines will break with config like udev and systemd in share/. This is not a *natural* place at all. What would break in particular? From a quick grep there is not a single mention of lib64 in any of the configuration/control files in either /lib/systemd or /lib/udev on my F16 system. We tend to interpret /usr/share as something today, to place stuff into that is really *shared* on the same host, like icons, man pages, things that are mere a collection of similar stuff that multiple packages use. Again, who is we here? FHS is pretty explicit about the intended distinction between lib and share. (And FWIW, none my comments above is to be read to be in favor of moving anything just to make things prettier or more consistent.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Lun 20 février 2012 21:07, Kay Sievers a écrit : On Mon, Feb 20, 2012 at 20:42, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 20 février 2012 18:50, Kay Sievers a écrit : On Feb 20, 2012 6:25 PM, Toshio Kuratomi a.bad...@gmail.com wrote: Udev rules and systemd units belong to the installed daemon. This daemon can only exist exactly one single time, and never be installed by multilib packages, hence they do not ever belong into libdir. Actually, Udev rules and systemd units belong to the package that installed them. That's why hiding them in a private lib dir is wrong When amavisd instaciates clamav using the generic unit shipped with clamav but using an amavisd-specific conf file the clamav systemd unid is shared with amavisd That's why share is the natural place to share this arch-independant configuration and putting it in /usr/lib is grandfathering an exception that only existed because /share didn't exist I couldn't disagree more. /usr/share in our general understanding not to be used for package-private things. But those files are not package-private! Even ignoring the example I just gave, systemd units *will* be installed by different packages that *will* need to be at least aware of the other units to handle ordering properly. Those files are anything but package-private -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers kay.siev...@vrfy.org wrote: The general rule for $libdir is that it is reserved for shared objects and their directly associated files like pkgconfig files. No, that's not at all what the FHS says. Please don't claim that any suggested meaning, however reasonable it may be, is the general rule when it isn't. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Lun 20 février 2012 21:20, Nicolas Mailhot a écrit : Le Lun 20 février 2012 21:07, Kay Sievers a écrit : I couldn't disagree more. /usr/share in our general understanding not to be used for package-private things. But those files are not package-private! Even ignoring the example I just gave, systemd units *will* be installed by different packages that *will* need to be at least aware of the other units to handle ordering properly. Those files are anything but package-private (and actually it's quite ridiculous to have systemd people argue today unit files belong to them alone when they've spent the past years reusing files that were intended for sysv. Someday something better than systemd will be proposed and it will have to read 'systemd' files just like systemd had to read 'sysv' files to handle the transition) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
2012/2/20 Miloslav Trmač m...@volny.cz: On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers kay.siev...@vrfy.org wrote: The general rule for $libdir is that it is reserved for shared objects and their directly associated files like pkgconfig files. No, that's not at all what the FHS says. Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. Please don't claim that any suggested meaning, however reasonable it may be, is the general rule when it isn't. I do. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 9:29 PM, Kay Sievers kay.siev...@vrfy.org wrote: 2012/2/20 Miloslav Trmač m...@volny.cz: On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers kay.siev...@vrfy.org wrote: The general rule for $libdir is that it is reserved for shared objects and their directly associated files like pkgconfig files. No, that's not at all what the FHS says. Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory, all architecture-dependent data exclusively used by the application must be placed within that subdirectory. That's the /usr/lib paragraph. The $libdir paragraph is 4.8.1.�Purpose /usr/libqual performs the same role as /usr/lib for an alternate binary format, except that the symbolic links /usr/libqual/sendmail and /usr/libqual/X11 are not required. [28] i.e. equivalent to /usr/lib, no additional restrictions. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Mon, Feb 20, 2012 at 21:25, Nicolas Mailhot nicolas.mail...@laposte.net wrote: Le Lun 20 février 2012 21:20, Nicolas Mailhot a écrit : Le Lun 20 février 2012 21:07, Kay Sievers a écrit : I couldn't disagree more. /usr/share in our general understanding not to be used for package-private things. But those files are not package-private! Even ignoring the example I just gave, systemd units *will* be installed by different packages that *will* need to be at least aware of the other units to handle ordering properly. Those files are anything but package-private (and actually it's quite ridiculous to have systemd people argue today unit files belong to them alone when they've spent the past years reusing files that were intended for sysv. Someday something better than systemd will be proposed and it will have to read 'systemd' files just like systemd had to read 'sysv' files to handle the transition) It all started with udev 7 years ago, and it still makes sense taking into account all the experience we collected in that time. Find it ridiculous or not, it's what we think is right. Even if we were not sure about it, changing the well-established way we do it would not be justified. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
systemd system unit files and UsrMove
I'm a fan of systemd [1]. And although I didn't like the fact that unit files were stored in /lib, I understood the rationale since there was no /share. However, I've just recently discovered [2] that after UsrMove unit files will be stored in /usr/lib. Can we not do better than this? And I'd really rather not work around the problem [3]. Seriously, please don't do this. Nathaniel 1 - http://nathaniel.themccallums.org/2012/01/28/systemd-rocks-my-world/ 2 - https://bugzilla.redhat.com/show_bug.cgi?id=791229 3 - https://bugzilla.redhat.com/show_bug.cgi?id=794777 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Fri, Feb 17, 2012 at 10:46:58AM -0500, Nathaniel McCallum wrote: I'm a fan of systemd [1]. And although I didn't like the fact that unit files were stored in /lib, I understood the rationale since there was no /share. However, I've just recently discovered [2] that after UsrMove unit files will be stored in /usr/lib. Can we not do better than this? And I'd really rather not work around the problem [3]. Seriously, please don't do this. Nathaniel 1 - http://nathaniel.themccallums.org/2012/01/28/systemd-rocks-my-world/ 2 - https://bugzilla.redhat.com/show_bug.cgi?id=791229 3 - https://bugzilla.redhat.com/show_bug.cgi?id=794777 Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18). Which are you advocating? -Toshio pgpt5KCshfHMN.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Fri, Feb 17, 2012 at 11:48 AM, Toshio Kuratomi a.bad...@gmail.comwrote: On Fri, Feb 17, 2012 at 10:46:58AM -0500, Nathaniel McCallum wrote: I'm a fan of systemd [1]. And although I didn't like the fact that unit files were stored in /lib, I understood the rationale since there was no /share. However, I've just recently discovered [2] that after UsrMove unit files will be stored in /usr/lib. Can we not do better than this? And I'd really rather not work around the problem [3]. Seriously, please don't do this. Nathaniel 1 - http://nathaniel.themccallums.org/2012/01/28/systemd-rocks-my-world/ 2 - https://bugzilla.redhat.com/show_bug.cgi?id=791229 3 - https://bugzilla.redhat.com/show_bug.cgi?id=794777 Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18). Which are you advocating? Move systemd unit files to /usr/share and provide simple logic to fall back /lib, so as not to break upgrades with custom unit files. I am certainly not advocating a bad user experience. If the schedule doesn't permit it, I'm ok with delaying the move to /usr/share until f18. However, I would want to avoid two moves at all costs. I can't imagine moving them to /usr/shared is a huge task (considering any bugs you would hit would likely already be hit by UsrMove anyway) or that moving the unit files from /lib to /usr/share is any different than moving them from /lib to /usr/lib. So the upgrade experience can't be really harmed by such a move. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On 02/17/2012 04:48 PM, Toshio Kuratomi wrote: Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18). Which are you advocating? If you are going to move units to /usr/share I suspect you want to move the rest as well udev, modprobe, depmod, tmpfiles, modules-load etc... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Am 17.02.2012 18:00, schrieb Nathaniel McCallum: Move systemd unit files to /usr/share and provide simple logic to fall back /lib, so as not to break upgrades with custom unit files. I am certainly not advocating a bad user experience. If the schedule doesn't permit it, I'm ok with delaying the move to /usr/share until f18. However, I would want to avoid two moves at all costs. I can't imagine moving them to /usr/shared is a huge task (considering any bugs you would hit would likely already be hit by UsrMove anyway) or that moving the unit files from /lib to /usr/share is any different than moving them from /lib to /usr/lib. So the upgrade experience can't be really harmed by such a move. you are missing the point that /lib/ to /usr/lib is a theoretical not invasive change by replacing /lib with a symlink! moving things around the filesystem means you are breaking each sort of scripts and whatever customized software is runnign at the users machines - can we please stop to enforce permanently chaning paths all over the world for some beautniess reason without any technical point for it signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
2012/2/17 Jóhann B. Guðmundsson johan...@gmail.com On 02/17/2012 04:48 PM, Toshio Kuratomi wrote: Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18). Which are you advocating? If you are going to move units to /usr/share I suspect you want to move the rest as well udev, modprobe, depmod, tmpfiles, modules-load etc... Sure, as time permits and when such can be done without harming user experience. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Fri, Feb 17, 2012 at 12:04 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 17.02.2012 18:00, schrieb Nathaniel McCallum: Move systemd unit files to /usr/share and provide simple logic to fall back /lib, so as not to break upgrades with custom unit files. I am certainly not advocating a bad user experience. If the schedule doesn't permit it, I'm ok with delaying the move to /usr/share until f18. However, I would want to avoid two moves at all costs. I can't imagine moving them to /usr/shared is a huge task (considering any bugs you would hit would likely already be hit by UsrMove anyway) or that moving the unit files from /lib to /usr/share is any different than moving them from /lib to /usr/lib. So the upgrade experience can't be really harmed by such a move. you are missing the point that /lib/ to /usr/lib is a theoretical not invasive change by replacing /lib with a symlink! I'm fine if you want to symlink /usr/lib/systemd/system to /usr/share/systemd/system or something else comparable. That should be just as noninvasive. My point is that custom files installed in /lib already have to be moved to /usr/lib. Why not also cleanly move systemd unit files to a more standard location? moving things around the filesystem means you are breaking each sort of scripts and whatever customized software is runnign at the users machines - can we please stop to enforce permanently chaning paths all over the world for some beautniess reason without any technical point for it Well, we've already decided to do these kinds of changes (aka UsrMove). If we are going to do so, why not do it right? Besides, we already have nice mechanisms like pkg-config variables to find the right paths for things, your scripts should use those. And what script is going to break by the move to /usr/share that won't be broken by the move to /usr/lib when the proper symlinks are in place? Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Am 17.02.2012 18:09, schrieb Nathaniel McCallum: 2012/2/17 Jóhann B. Guðmundsson johan...@gmail.com mailto:johan...@gmail.com On 02/17/2012 04:48 PM, Toshio Kuratomi wrote: Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18). Which are you advocating? If you are going to move units to /usr/share I suspect you want to move the rest as well udev, modprobe, depmod, tmpfiles, modules-load etc... Sure, as time permits and when such can be done without harming user experience. FOR WHAT REASON? such changes do ALWAYS harming user experience why? becaus eoperating systems are (or where it seems) made to give users the base for their own work, scripts, automatisms and the idea of linux once was give users a CUSTOMIZEABLE system by permanently change thins for the sake of the change you are killing the customizeable becasue it is better not do this at all to be safe for useless changes made from bored people upstream your OS PLEASE STOP THIS BAD ATTITUDE DAMAGE PERMANENTLY CUSTOMIZED SYSTEMS JUST FOR FUN OR YOU WILL NEVER IN THIS LIFE HAVE USERS USING LINUX IF THEY WANT TO DO MORE THAN INSERT A DVD AND EAT WHAT SOMEONE OTHER DECIDED IS GOOD FOR THEM signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On 02/17/2012 05:09 PM, Nathaniel McCallum wrote: Sure, as time permits and when such can be done without harming user experience. Why bother only with unit files? Users never touch those the ones in /lib/systemd/system or /usr/lib/systemd/system anyway so there is no breakage for them... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Am 17.02.2012 18:16, schrieb Nathaniel McCallum: On Fri, Feb 17, 2012 at 12:04 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 17.02.2012 18:00, schrieb Nathaniel McCallum: Move systemd unit files to /usr/share and provide simple logic to fall back /lib, so as not to break upgrades with custom unit files. I am certainly not advocating a bad user experience. If the schedule doesn't permit it, I'm ok with delaying the move to /usr/share until f18. However, I would want to avoid two moves at all costs. I can't imagine moving them to /usr/shared is a huge task (considering any bugs you would hit would likely already be hit by UsrMove anyway) or that moving the unit files from /lib to /usr/share is any different than moving them from /lib to /usr/lib. So the upgrade experience can't be really harmed by such a move. you are missing the point that /lib/ to /usr/lib is a theoretical not invasive change by replacing /lib with a symlink! I'm fine if you want to symlink /usr/lib/systemd/system to /usr/share/systemd/system or something else comparable. That should be just as noninvasive. My point is that custom files installed in /lib already have to be moved to /usr/lib. Why not also cleanly move systemd unit files to a more standard location? currently /lib will be linked to /usr/lib what you are proposing is braindead moving around things and replace all of them by more and more symlinks all over the system for what reason? fun to do changes? why are you not starting to develop a software on your own if you are borded and leave people which are happy with working systems in peace? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Fri, Feb 17, 2012 at 12:17 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 17.02.2012 18:09, schrieb Nathaniel McCallum: 2012/2/17 Jóhann B. Guðmundsson johan...@gmail.com mailto: johan...@gmail.com On 02/17/2012 04:48 PM, Toshio Kuratomi wrote: Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18). Which are you advocating? If you are going to move units to /usr/share I suspect you want to move the rest as well udev, modprobe, depmod, tmpfiles, modules-load etc... Sure, as time permits and when such can be done without harming user experience. FOR WHAT REASON? such changes do ALWAYS harming user experience why? becaus eoperating systems are (or where it seems) made to give users the base for their own work, scripts, automatisms and the idea of linux once was give users a CUSTOMIZEABLE system by permanently change thins for the sake of the change you are killing the customizeable becasue it is better not do this at all to be safe for useless changes made from bored people upstream your OS PLEASE STOP THIS BAD ATTITUDE DAMAGE PERMANENTLY CUSTOMIZED SYSTEMS JUST FOR FUN OR YOU WILL NEVER IN THIS LIFE HAVE USERS USING LINUX IF THEY WANT TO DO MORE THAN INSERT A DVD AND EAT WHAT SOMEONE OTHER DECIDED IS GOOD FOR THEM So we should never change anything, right? Tone down the rhetoric please. I'm asking for gradual evolution here without pain. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Am 17.02.2012 18:20, schrieb Nathaniel McCallum: Sure, as time permits and when such can be done without harming user experience. FOR WHAT REASON? such changes do ALWAYS harming user experience why? becaus eoperating systems are (or where it seems) made to give users the base for their own work, scripts, automatisms and the idea of linux once was give users a CUSTOMIZEABLE system by permanently change thins for the sake of the change you are killing the customizeable becasue it is better not do this at all to be safe for useless changes made from bored people upstream your OS PLEASE STOP THIS BAD ATTITUDE DAMAGE PERMANENTLY CUSTOMIZED SYSTEMS JUST FOR FUN OR YOU WILL NEVER IN THIS LIFE HAVE USERS USING LINUX IF THEY WANT TO DO MORE THAN INSERT A DVD AND EAT WHAT SOMEONE OTHER DECIDED IS GOOD FOR THEM So we should never change anything, right? Tone down the rhetoric please. I'm asking for gradual evolution here without pain. i do NOT TONE DOWN you are asking for changes nobody needs where did i say never change anything i said do not things that are ain't broken if you are bored searh for work but not for changeing things working to produce all sort of bugs over the long which are giving you work again by try to fix them where does /lib/systemd hurt you? where does most other locations currently used hurt you? why are they hurting you? are they hurting you so bad that you do not find any useful work to do instead proposing changes for the sake of the change? i am one of the idiots who have to deal with useless chnages stealing me the time to make useful ones in software dveloped by me - so what do you think which sort of answer yiu get propose stealing more and more of my time for NOTHING? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Fri, 2012-02-17 at 17:17 +, Jóhann B. Guðmundsson wrote: On 02/17/2012 05:09 PM, Nathaniel McCallum wrote: Sure, as time permits and when such can be done without harming user experience. Why bother only with unit files? Users never touch those the ones in /lib/systemd/system or /usr/lib/systemd/system anyway so there is no breakage for them... Well, as we discussed the other day on IRC, we pretty much all agreed that it's not in the spirit of the FHS to have these files in /lib or /usr/lib. The only reason they were ever in /lib to begin with is because /share didn't exist (and at the time we were (correctly) positioning systemd as being prefix=/ and not prefix=/usr). signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On 2012-02-17 10:28, Stephen Gallagher wrote: On Fri, 2012-02-17 at 17:17 +, Jóhann B. Guðmundsson wrote: On 02/17/2012 05:09 PM, Nathaniel McCallum wrote: Sure, as time permits and when such can be done without harming user experience. Why bother only with unit files? Users never touch those the ones in /lib/systemd/system or /usr/lib/systemd/system anyway so there is no breakage for them... Well, as we discussed the other day on IRC, we pretty much all agreed that it's not in the spirit of the FHS to have these files in /lib or /usr/lib. The only reason they were ever in /lib to begin with is because /share didn't exist (and at the time we were (correctly) positioning systemd as being prefix=/ and not prefix=/usr). That wasn't the impression I got. Some people at least seemed to be arguing that /usr/share was no more 'correct' for systemd unit files than /usr/lib/systemd is. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Feb 17, 2012, at 10:20 AM, Nathaniel McCallum wrote: Tone down the rhetoric please. I'm no expert, but I think the UsrMove issue has pushed some people beyond anxiety disorder. MDMA or diazepam would probably have a higher efficacy than more emails on the subject. Chris Murphy-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Ven 17 février 2012 18:02, Jóhann B. Guðmundsson a écrit : On 02/17/2012 04:48 PM, Toshio Kuratomi wrote: Yeah -- so I see three options -- move systemd unit files to /usr/share, revert /usr/move, change rpmlint (or a fourth -- ignore this warning for f17 and move systemd unit files to /usr/share for f18). Which are you advocating? If you are going to move units to /usr/share I suspect you want to move the rest as well udev, modprobe, depmod, tmpfiles, modules-load etc... That would be a worthwhile cleanup and make startup services behave like normal apps at last (and usermove ils all about cleaning up historical FHS peculiarities) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
Le Ven 17 février 2012 18:40, Adam Williamson a écrit : On 2012-02-17 10:28, Stephen Gallagher wrote: Well, as we discussed the other day on IRC, we pretty much all agreed that it's not in the spirit of the FHS to have these files in /lib or /usr/lib. The only reason they were ever in /lib to begin with is because /share didn't exist (and at the time we were (correctly) positioning systemd as being prefix=/ and not prefix=/usr). That wasn't the impression I got. Some people at least seemed to be arguing that /usr/share was no more 'correct' for systemd unit files than /usr/lib/systemd is. Trying to distinguish between code and data is a lost cause. arch independant vs arch dependant is a clean simple boundary and the one fedora has historically supported (look where lisp or java code is today) -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd system unit files and UsrMove
On Fri, Feb 17, 2012 at 06:25:23PM +0100, Reindl Harald wrote: Am 17.02.2012 18:20, schrieb Nathaniel McCallum: Sure, as time permits and when such can be done without harming user experience. FOR WHAT REASON? such changes do ALWAYS harming user experience why? becaus eoperating systems are (or where it seems) made to give users the base for their own work, scripts, automatisms and the idea of linux once was give users a CUSTOMIZEABLE system by permanently change thins for the sake of the change you are killing the customizeable becasue it is better not do this at all to be safe for useless changes made from bored people upstream your OS PLEASE STOP THIS BAD ATTITUDE DAMAGE PERMANENTLY CUSTOMIZED SYSTEMS JUST FOR FUN OR YOU WILL NEVER IN THIS LIFE HAVE USERS USING LINUX IF THEY WANT TO DO MORE THAN INSERT A DVD AND EAT WHAT SOMEONE OTHER DECIDED IS GOOD FOR THEM So we should never change anything, right? Tone down the rhetoric please. I'm asking for gradual evolution here without pain. i do NOT TONE DOWN You really should. you are asking for changes nobody needs Because, while there are relevant objections to features being presented, the manner in which you present them means that people want to dismiss them. In fact, your tone has become so over the top that people have gone from wanting to dismiss to actually dismissing them. Unless you are trying to use reverse psychology, this is serving nobody's interests. -Toshio pgph7pqM67j9y.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
