Re: systemd system unit files and UsrMove

[Miloslav Trmač]

On Wed, Feb 22, 2012 at 7:46 AM, Harald Hoyer  wrote:
> Am 21.02.12 14:37, schrieb Miloslav Trmač:
>> On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer  
>> wrote:
>>> Am 20.02.2012 21:19, schrieb Miloslav Trmač:
 On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers  wrote:
> There is no reason to have
> /usr/share// and /usr/lib/, 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.


> 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

[Harald Hoyer]

Am 21.02.12 14:37, schrieb Miloslav Trmač:
> On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer  wrote:
>> Am 20.02.2012 21:19, schrieb Miloslav Trmač:
>>> On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers  wrote:
 There is no reason to have
 /usr/share// and /usr/lib/, 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

[Toshio Kuratomi]

On Mon, Feb 20, 2012 at 09:17:30PM +0100, Kay Sievers wrote:
> On Mon, Feb 20, 2012 at 20:18, Toshio Kuratomi  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

[Miloslav Trmač]

On Tue, Feb 21, 2012 at 11:06 AM, Harald Hoyer  wrote:
> Am 20.02.2012 21:19, schrieb Miloslav Trmač:
>> On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers  wrote:
>>> There is no reason to have
>>> /usr/share// and /usr/lib/, 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

[Harald Hoyer]

Am 20.02.2012 21:19, schrieb Miloslav Trmač:
> On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers  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// and /usr/lib/, 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

[Kay Sievers]

On Mon, Feb 20, 2012 at 21:25, Nicolas Mailhot
 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

Re: systemd system unit files and UsrMove

[Miloslav Trmač]

On Mon, Feb 20, 2012 at 9:29 PM, Kay Sievers  wrote:
> 2012/2/20 Miloslav Trmač :
>> On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers  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/lib performs the same role as /usr/lib for an alternate
binary format, except that the symbolic links /usr/lib/sendmail
and /usr/lib/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

[Kay Sievers]

2012/2/20 Miloslav Trmač :
> On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers  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

[Nicolas Mailhot]

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

[Miloslav Trmač]

On Mon, Feb 20, 2012 at 9:17 PM, Kay Sievers  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

[Nicolas Mailhot]

Le Lun 20 février 2012 21:07, Kay Sievers a écrit :
> On Mon, Feb 20, 2012 at 20:42, Nicolas Mailhot
>  wrote:
>>
>> Le Lun 20 février 2012 18:50, Kay Sievers a écrit :
>>> On Feb 20, 2012 6:25 PM, "Toshio Kuratomi"  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

[Miloslav Trmač]

On Mon, Feb 20, 2012 at 9:07 PM, Kay Sievers  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// and /usr/lib/, 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

[Kay Sievers]

On Mon, Feb 20, 2012 at 20:18, Toshio Kuratomi  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

[Kay Sievers]

On Mon, Feb 20, 2012 at 20:42, Nicolas Mailhot
 wrote:
>
> Le Lun 20 février 2012 18:50, Kay Sievers a écrit :
>> On Feb 20, 2012 6:25 PM, "Toshio Kuratomi"  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// and /usr/lib/, 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

[Nicolas Mailhot]

Le Lun 20 février 2012 18:50, Kay Sievers a écrit :
> On Feb 20, 2012 6:25 PM, "Toshio Kuratomi"  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

[Nicolas Mailhot]

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

[Toshio Kuratomi]

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

[Kay Sievers]

On Feb 20, 2012 6:25 PM, "Toshio Kuratomi"  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/. 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

[Lennart Poettering]

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

[Toshio Kuratomi]

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

[Nils Philippsen]

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

[Kay Sievers]

On Mon, Feb 20, 2012 at 13:51, Lennart Poettering  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

[Vít Ondruch]

Dne 20.2.2012 13:51, Lennart Poettering napsal(a):

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.


No more for Ruby ...

Vit

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd system unit files and UsrMove

[Lennart Poettering]

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

[Nicolas Mailhot]

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

[Lennart Poettering]

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

[Toshio Kuratomi]

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

Re: systemd system unit files and UsrMove

[Nicolas Mailhot]

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

[Nicolas Mailhot]

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

[Chris Murphy]

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

[Adam Williamson]

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

[Stephen Gallagher]

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

[Reindl Harald]

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

[Nathaniel McCallum]

On Fri, Feb 17, 2012 at 12:17 PM, Reindl Harald wrote:

>
>
> Am 17.02.2012 18:09, schrieb Nathaniel McCallum:
> >
> >
> > 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.
>
> 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

[Reindl Harald]

Am 17.02.2012 18:16, schrieb Nathaniel McCallum:
> On Fri, Feb 17, 2012 at 12:04 PM, Reindl Harald  > 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

[Jóhann B. Guðmundsson]

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

[Reindl Harald]

Am 17.02.2012 18:09, schrieb Nathaniel McCallum:
> 
> 
> 2012/2/17 "Jóhann B. Guðmundsson"  >
> 
> 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

[Nathaniel McCallum]

On Fri, Feb 17, 2012 at 12:04 PM, Reindl Harald 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?


> 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

[Nathaniel McCallum]

2012/2/17 "Jóhann B. Guðmundsson" 

> 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

[Reindl Harald]

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

[Jóhann B. Guðmundsson]

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

[Nathaniel McCallum]

On Fri, Feb 17, 2012 at 11:48 AM, Toshio Kuratomi wrote:

> 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

[Toshio Kuratomi]

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

systemd system unit files and UsrMove

[Nathaniel McCallum]

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