Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-06 Thread David Kaylor
> I interpreted this thread as a bug report with 'The Arch Way' page on
> the wiki so it hasn't been for naught. That page has been rewritten to
> better reflect what has always been the development philosophy instead
> of being a vague advertisement for the distribution with questionable
> claims.
>
> https://wiki.archlinux.org/index.php/The_Arch_Way
>
> It's not perfect, but it's a lot more grounded in reality now.
>
>
I have to say, well done Daniel. Glad something useful finally emerged from
this thread.


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-06 Thread Daniel Micay
While technical debate can be productive when it's not simply rehasing
the same things over and over again, simply voicing opinions is not. I
don't think it would be a good idea to develop any distribution based
upon the opinions of whoever shouts the loudest.

Decisions are made based on consensus among the people doing the work
whether they are Arch developers, trusted users or other contributors in
the community without those fancy titles. Arch isn't striving for
popularity so the popularity of the decisions among the users isn't
important. It's developed for the people doing the work.

I interpreted this thread as a bug report with 'The Arch Way' page on
the wiki so it hasn't been for naught. That page has been rewritten to
better reflect what has always been the development philosophy instead
of being a vague advertisement for the distribution with questionable
claims.

https://wiki.archlinux.org/index.php/The_Arch_Way

It's not perfect, but it's a lot more grounded in reality now.



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-06 Thread Eduardo Machado
2015-07-02 18:46 GMT-03:00 Daniel Micay :

> > Now, it would be technically possible to replace *systemd* in base with a
> > generic "init-system" which could be provided by both *systemd* and
> *openrc*,
> > but that would make things much more complicated and *much* more effort
> to
> > maintain.
>
> Packages don't have a dependency on systemd because they need an init
> system. They have a dependency on systemd IPC interfaces and/or
> libraries not provided by openrc. If they depend on systemd without
> needing something like this, it's a (very minor) bug to report.
>
> Supporting alternative implementations of those interfaces (like
> Debian's systemd-shim) would mean a lot of extra work across the
> distribution.
>
> Arch supports one specific /bin/sh implementation, one standard C
> library, one standard C++ library, one C++ exception model, one
> toolchain for building the system, etc. It also tends to only support
> one specific implementation of a command-line utility as the main tool
> and others have to be namespaced. Packages like util-linux/coreutils
> aren't split into little pieces and there's no equivalent to
> update-alternatives. Sure, packages like musl, libc++, libc++abi and
> busybox are in the repositories but not in a way that can actually
> replace anything in the base system, it just lives alongside it without
> being used by any other packages.
>
> Arch only ever supported one init system until the transition period to
> systemd where it supported two. The old initscripts adopted systemd
> utilities like systemd-tmpfiles before going away anyway, and the old
> scripts were still supported. It was convergence to a single supported
> init system rather than two choices for the base system living alongside
> each other.
>
> Making technical decisions and then going through with them with proper
> integration into other packages is the only way that things are going to
> be polished. The alternative is a *lot* of extra complexity, development
> effort and bugs.
>
>
Hi Daniel,

i wanna apologize if i misspelled something and made more damage than good.

And this post of yours is what i am certain that all the users would like
to see, and i have to commed.
It was a kind of polite and really technical note.

I know that when we work in projects like this, we work almost for love,
it's demanding and sometimes we get frustrating with the feeling that our
work are not getting recognized.
I'm sure it is not the case for anyone here, but when we see a phrase like
"the user opinion has no weight" it generates the same feeling that i tried
to describe above.

Note that I am not advocating any solution. but what i would like to hear
is that de devs heard the users, technically and non-technically opinions,
weighted them with the pros and cons, and them choosed a solution with some
benefits.

Didn't you agree that this is a really better statement? ;)


Best regards, and again, sorry, i didn't want to polemize.


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-03 Thread Mike Cloaked
On Fri, Jul 3, 2015 at 4:10 PM, Geoff  wrote:

> On Fri, 3 Jul 2015 16:51:21 +0200
> Bardur Arantsson  wrote:
>
> 
> > STOP!
>
> Although I find the discussion interesting, I have watched with growing
> amazement.  As I recall, this list became moderated due to the furore when
> systemd was introduced, and I doubt that Lennart himself could have got a
> post
> on the subject through in the aftermath.
>

The bitter flame wars concerning systemd were rife on several other mailing
lists a few years ago and led to no useful outcome other than to severely
impact on users who had significant volumes of mail in their inboxes. This
led both to some MLs being moderated but also led to some people
unsubscribing from lists to get away from the futile claim and counterclaim
spew of mail. Please stop this systemd discussion now as the majority of
people in this list are subscribed for the purpose of providing and
receiving genuine help with issues that can't be answered in the wiki or
forums. Also suggestions for positive developments that have not been
discussed elsewhere.

Times have moved on since the systemd war - and we have a very functional
arch linux operating system. Please move any further systemd rants to some
other channel.
-- 
mike c


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-03 Thread Geoff
On Fri, 3 Jul 2015 16:51:21 +0200
Bardur Arantsson  wrote:


> STOP!

Although I find the discussion interesting, I have watched with growing
amazement.  As I recall, this list became moderated due to the furore when
systemd was introduced, and I doubt that Lennart himself could have got a post
on the subject through in the aftermath.

Geoff


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-03 Thread Bardur Arantsson
On 07/03/2015 04:31 PM, Tobias Hunger wrote:
> To be fair: There is more to here than "Unix philosophy" and "I hate Lennart".
> 

STOP!

Can we please end this discussion now?

This no longer has anything to do with Arch Linux and is just spam (for
this list) at this point.

I'm sure people who are interested can find other places to discuss the
merits (or otherwise) of systemd.

Regards,


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-03 Thread Tobias Hunger
To be fair: There is more to here than "Unix philosophy" and "I hate Lennart".

Number 1 is "systemd is a monolithic mess" and reveals a glaring
misunderstanding of layered architectures. He is basically claiming
that kernel/xorg/browser is one mess since the browser won't start
without the kernel and xorg running at the same time.

Number 2 about "everybody uses systemd" is barking up the wrong tree:
The question is not "Why do distributions adopt systemd?", it is "Why
do developers adopt systemd?". Distributions have to tag along for the
ride once enough developers use the stuff. He sees that ("A big
motivating factor is that other application suites (e.g. GNOME)
increasingly depend on it to work."), but does not bother to examine
that issue.

Number 2 is "systemd is not for every use case" and he is actually
right with that.

Number 4 is about shell scripting and that you could have shell
scripts that are as clean as systemd unit files... if that was true,
then at least one distribution would have managed that in the last
couple of decades. He is right that systemd does not reduce complexity
though, it just moves it into a different place. That in itself is a
big achievement though.

Number 5 is "you can use Linux specific features without systemd",
which is correct, but it is less convenient to do, so nobody bothered.
Systemd did make many of those features mainstream.

Number 6 is "No other init provides anything of value to userspace
(besides starting stuff), so systemd is evil for doing that."

Number 7 is "all the claimed benefits of systemd can be archived
differently", which is obviously correct. Pretty close to Number 5
though.

Number 8 is "but everything does indirectly depend on systemd as init,
not just on services provided by things in higher layers", which is
just another misunderstanding of a layered architecture.

Number 9 boils down to "systemd is too complex for some use cases". He
is right there, just as he was in Number 2 before.

Number 10 is the boring binary logging again. Nothing new here... but
he raises one interesting question: Why have a journal when it can
just forward to syslog? Because systemd needs to log stuff, even when
syslog is not yet running or was already stopped. So it needs to
either throw away the logs (which is what sysv init did) or it needs
to have some internal interface that makes sure stuff is not lost and
can optionally interface with syslog when that is available. That is
pretty much what the journal is. It did grow a bit from there once it
became clear that it is useful.

Number 11 is "I do not like Lennart", which I actually consider to be
a valid point. He is right in claiming that there is a social
component to projects and that this does influence the selection of
software one is comfortable to run.

Number 12 is "the kernel is complex is no excuse for systemd being
complex". Mostly another misunderstanding about layered architectures
that again result in the claim that systemd is a entangled mess.

Number 13 is "most of systemd was written by just a handful of
people", which is true for any open source project. IMHO that does not
diminish the value of having many contributors at all: Those did read
(parts of) the code and they do provide feedback and what not.

And that's it...

Best Regards,
Tobias


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-03 Thread Yaro Kasear
I can't overtly fault the logic in that blog post for the most part.
However he does still basically toe the "Unix philosophy" line (Talking
about modularity and such.)

The thing that bothers me most about this document though is how he
dismisses systemd's legitimate, if not unique, features as "propaganda." He
also tends to talk about flaws in how systemd is written but doesn't seem
to explain that, go into rants about Poettering not long after dismissing
one of the common statements being "you just hate systemd because
Poeterring," etc.

I must be that rare breed of systemd supporter who actually actively
DISLIKES Poettering. When he started Pulseaudio and it started breaking
everyone's sound, he went into a mantra of "ALSA's broken" instead, despite
the fact ALSA, even standalone, worked just fine without PA. That said I
now use Pulseaudio, because once it matured it stopped breaking sound as
much. I'm not a fan of how it demands to "own" all sound on the system, but
I can get over that.

Add point 5, though, to the typical anti-systemd rants when boiled down: 5:
I hate Lennart Poeterring.


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-03 Thread Tobias Hunger
On Fri, Jul 3, 2015 at 1:10 PM, LoneVVolf  wrote:
> This blog post gives the best description of systemd flaws i am aware of :
> http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html

That is one of the worst descriptions of problems in systemd that I am
aware of:-)

The author completely misses that systemd is a layered architecture
which at its core provides (mostly) a convenient cgroups interface.
Other services are layered on top of that core functionality and in
turn provide more interfaces, that in turn other services depend upon.

None of the other init system can provide similar basic services, so
none can even come close to replacing systemd at this time. That is
actually a bit sad, a bit of competition has never hurt:-)

Best Regards,
Tobias


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-03 Thread Yaro Kasear
On Jul 3, 2015 6:10 AM, "LoneVVolf"  wrote:
>
> Some general comments :
>
> - Openrc is a replacement for sysv init, not an addition.
>

OpenRC runs on SysV Init last I checked, as OpenRC is just highly polished
initscripts. How is that a replacement instead of an addition?

> - openrc has it's own equivalent of .service files, they are simpler then
systemd servicefiles.

I admit I have not looked at OpenRC service files. But systemd units are
barely even 6 lines not counting empty lines.

> - my personal opinion about openrc is that it's not mature enough yet for
majority of linux users to replace systemd

My opinion is because it stoll relies on things Linux desperately needs to
be rid of. Systemd has the advantages of both actually ridding us of SysV
Init snd ysing vsrious kernel features OpenRC simply can't do to being
initscripts.

> The majority of Arch users however should be capable enough to use it
efficiently.
>

I have no argumemt here. But I still feel systemd is the better option.

> - systemd has many good things, but also many flaws.
>

OpenRC does too. Not the least of which is that it is not actually an init
replacement. Make OpenRC an independent init system then it will be a
serious contender.

> This blog post gives the best description of systemd flaws i am aware of :
> http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html

I will look this over. But I have already seen a bunch of systemd rants
over the years snd they always boil down to the same points:

1. Unix philosophy, as if it was some sort of gospel when even most bona
fide Unix systems don't even follow it any more.
2. Feature creep, about the only legitimate gripe I have seen.
3. Blaming the decisions of other projects bad decisionmaking on systemd.
GNOME 3 is a classic example.
4. Change Is Bad (tm), usually taking the form of the commentator wanting
to cling to initscripts.

>
> LVV


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-03 Thread LoneVVolf

Some general comments :

- Openrc is a replacement for sysv init, not an addition.

- openrc has it's own equivalent of .service files, they are simpler 
then systemd servicefiles


- my personal opinion about openrc is that it's not mature enough yet 
for majority of linux users to replace systemd
The majority of Arch users however should be capable enough to use it 
efficiently.


- systemd has many good things, but also many flaws.

This blog post gives the best description of systemd flaws i am aware of :
http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html

LVV


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-03 Thread Henrik Danielsson
2015-07-03 6:45 GMT+02:00 Yaro Kasear :
>
> I wouldn't mind some spiritual successor to systemd where its entire
> purpose is to be init, without sacrificing some of the more useful/powerful
> features like cgroups, concurrency, and the like. Systemd went wrong when
> it started going into stuff that init itself really doesn't need to manage
> on its own.

Well, to be fair, systemd [the process or as a concept] isn't managing it
all on its own, there are separate tools for the tasks under the systemd
label. The developers saw usefulness in having these tools to keep a better
eye on things, and I do think we've gained some benefits over other "pure
init"-systems this way. Optimal or not, I don't care. It has at least been
a lot easier for me to manage, as a user, compared to parsing tons of
different script only to find out what they're trying to do or if any of
them even have the same features.

That's just my experience after switching to Arch to try systemd when the
transition was made. I'm still around because I think the way Arch
integrates software feels "cleaner" compared to many other distros.

Thank you to all the developers and users who have helped me out directly
or indirectly. We don't need to agree on everything before a decision is
made. As long as a decision is made in either direction and Arch keeps
moving, we could always go somewhere else later if need be.


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Yaro Kasear
I personally prefer systemd over the alternatives. I grant there's
considerable feature creep, but the people who complain a lot either don't
offer an alternative, or the one alternative they offer is the frankly
broken system Linux had been using since the dawn of time.

I wouldn't mind some spiritual successor to systemd where its entire
purpose is to be init, without sacrificing some of the more useful/powerful
features like cgroups, concurrency, and the like. Systemd went wrong when
it started going into stuff that init itself really doesn't need to manage
on its own.

SysV Init needs to die, let's move on. OpenRC is not enough to save it.

On Thu, Jul 2, 2015 at 10:49 PM, Bardur Arantsson 
wrote:

> On 07/03/2015 12:19 AM, Daniel Micay wrote:
> >> WHAT? The opinion of users has no weight here ?!?!?!
> >
> [--snip--]
>
> Just to add a little bit to what Daniel said: Can we please calm down a
> bit here?
>
> It's not like there's no overlap between what developers want and what
> ordinary users want -- in fact there seems to be rather a lot of overlap
> given the number of users Arch has. Remember that developers are users too!
>
> (P.S. I'm not a developer/packager just an ordinary user.)
>


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Bardur Arantsson
On 07/03/2015 12:19 AM, Daniel Micay wrote:
>> WHAT? The opinion of users has no weight here ?!?!?!
> 
[--snip--]

Just to add a little bit to what Daniel said: Can we please calm down a
bit here?

It's not like there's no overlap between what developers want and what
ordinary users want -- in fact there seems to be rather a lot of overlap
given the number of users Arch has. Remember that developers are users too!

(P.S. I'm not a developer/packager just an ordinary user.)


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Daniel Micay
> WHAT? The opinion of users has no weight here ?!?!?!

Popular opinion has no weight. Zero. Technical arguments have weight but
most of them have already been debated for ages. There's a strong
consensus among the developers (and trusted users / other people who
contribute, but that's less important) in support of the status quo.

Additionally, if by 'here' you mean arch-general... most developers
probably don't subscribe to this list at all. It's used for requesting
help and flame wars. I'm quite sure that nothing said in this thread is
going to have any impact on Arch's development. There's little else to
be said about these topics. It's just a repeat of the same things over
and over again and that's exactly why it's not on the radar in terms of
development.

> I came to Arch because th way it is built and "marketed" looked like a real
> community and user centric, user centric not to be as easy as pushing a
> button, but in the way that i can install, configure, and use it the way i
> want to.
> Is that real?

It's a community distribution in the sense that the developers aren't
paid employees and there's no backing corporation. You can install,
configure and use it however you want but the developers are only going
to support the use cases they care about. In the base system, there's
usually *one* supported option for that component (glibc, libstdc++,
libsupc++, coreutils/util-linux, systemd, binutils/gcc, etc.). As a
binary distribution, it *has* to make many of these decisions, and
others like choosing one init system need to be made to have a polished,
maintainable distribution.

> If Arch is becoming a personal distribution to attend the developers, so
> let it clrealy in the website, so we consider choosing a new way.
> But to realize such an affirmation is a little bit dismotivating at minimum.

It has always been a distribution built around the technical views of
the developers. Unlike many other distributions, it doesn't try to
appeal to a broad audience. That's what makes it Arch rather than say a
distribution like OpenSUSE.

There's always room for more contributors, and they'll quickly become
trusted users / developers if they're talented and get along with the
other developers. The people doing the work are the ones making the
decisions, as things usually are in open source projects.

> The real POINT here is that, ANY decision made (not only systemd) have its
> pros and cons, but when someone ask for something different or question
> that, it is wise to listen, think, and answer in an polite way.
> Recently i am seeing much rage in talks, i think i will be better, and
> constructive, to filter better the words so that we can have a kind of a
> talk.

It's not like this is a technical discussion providing anything positive
for the distribution's development. It would be a lot more constructive
for everyone to avoid wasting time like this.

The constructive thing to do is accepting that Arch isn't a meta
distribution like Gentoo. It only supports choice *above* the layer of
the base system. You don't get to replace glibc, the toolchain, the core
utilities, the init system / core services (i.e. systemd), etc. without
venturing into extremely painful unsupported territory.

There are *lots* of other distributions, and most settle on either using
systemd or not supporting it *at all*, up to the point that unit files
are stripped out of packages (as Alpine does).



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Daniel Micay
> Now, it would be technically possible to replace *systemd* in base with a
> generic "init-system" which could be provided by both *systemd* and *openrc*,
> but that would make things much more complicated and *much* more effort to
> maintain.

Packages don't have a dependency on systemd because they need an init
system. They have a dependency on systemd IPC interfaces and/or
libraries not provided by openrc. If they depend on systemd without
needing something like this, it's a (very minor) bug to report.

Supporting alternative implementations of those interfaces (like
Debian's systemd-shim) would mean a lot of extra work across the
distribution.

Arch supports one specific /bin/sh implementation, one standard C
library, one standard C++ library, one C++ exception model, one
toolchain for building the system, etc. It also tends to only support
one specific implementation of a command-line utility as the main tool
and others have to be namespaced. Packages like util-linux/coreutils
aren't split into little pieces and there's no equivalent to
update-alternatives. Sure, packages like musl, libc++, libc++abi and
busybox are in the repositories but not in a way that can actually
replace anything in the base system, it just lives alongside it without
being used by any other packages.

Arch only ever supported one init system until the transition period to
systemd where it supported two. The old initscripts adopted systemd
utilities like systemd-tmpfiles before going away anyway, and the old
scripts were still supported. It was convergence to a single supported
init system rather than two choices for the base system living alongside
each other.

Making technical decisions and then going through with them with proper
integration into other packages is the only way that things are going to
be polished. The alternative is a *lot* of extra complexity, development
effort and bugs.



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Daniel Micay
On 02/07/15 02:34 PM, Neven Sajko wrote:
> Daniel Micay dixit:
>> The package isn't going to be split so it doesn't make much sense to
>> refer to libsystemd.
> 
> It is split:
> https://www.archlinux.org/packages/core/x86_64/libsystemd/

I know it's split into systemd, libsystemd and systemd-sysvcompat. The
split is there to break a cyclic dependency, and doesn't provide the
flexibility offered by Debian's systemd split including breaking up
libsystemd. They have it set up so you can run things like
systemd-logind without systemd as init (or installed at all).



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Sebastiaan Lokhorst
It is very simple. The bare minimum Arch install consist of the base
 group.

The user *must* install this group. If they don't, they no longer have a
minimal Arch install, so developers cannot help them. It is the *base* and
everything else builds on it.
It would make no sense to replace the *linux*, *filesystem* or *pacman*
package with something incompatible and expect everything to keep working.

Now, it would be technically possible to replace *systemd* in base with a
generic "init-system" which could be provided by both *systemd* and *openrc*,
but that would make things much more complicated and *much* more effort to
maintain.

Regards,
Sebastiaan


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Terry Z.
I am a bit disappointed to hear that there appears to be such a large
disconnect between the developer philosophy and the user philosophy in the
community.  Even the website itself (which granted in many cases simply
points to various wiki sections), tends to give the impression the Arch Way
and philosophy are user centric. In fact. It even has an entire "user
centric" point in it. To hear that this "Arch Way" is not an official
stance but something the community came up with is news to me.

I'm completely fine with the focus being entirely on simplicity and
minimalism from a dev standpoint.  There is something to be appreciated
there.  However, I feel that perhaps the community image may need some
clarity for that.  Looking at everything in The Arch Way wiki page (except
the user centric portion), as well as most other things I can easily see it
being taken either way.  And most of us may not be concerned with that dev
central focus being the philosophy applied as the developer's desires line
up with our use cases.

I believe though one of the biggest strengths of the free/open software
community is being able to make the decision to deal with something or not
after gathering the necessary information.  In this case, the presentation
of that information may require some clarity.  Heck, it's entirely possible
it is perfectly clear somewhere but just being missed by users.

On Thu, Jul 2, 2015 at 2:33 PM, Eduardo Machado 
wrote:

> 2015-07-02 10:24 GMT-03:00 Daniel Micay :
>
> > On 01/07/15 02:36 PM, João Miguel wrote:
> > > First of all, thank you for such a quick reply.
> > >
> > > Now, I don't want to preach. But I will not pretend I chose Arch Linux
> at
> > > random. I chose it for many reasons, an important one of them being
> that
> > > I liked the Arch Way, it made sense to me, and it seemed you were
> > > following it. Now it seems to belong to a forgotten past.
> > >
> > > On Wed, Jul 01, 2015 at 10:34:01AM -0400, Daniel Micay wrote:
> > >> Arch is as much a systemd-based distribution as it is a Pacman-based
> > >> distribution at this point. (...)
> > > Is it now? https://wiki.archlinux.org/index.php/The_Arch_Way
> >
> > That's an unprotected page on the wiki, not an authoritative source on
> > anything to do with the distribution.
> >
> > Arch has always been a simple distribution in terms of the developer
> > perspective, not the user one. Using systemd made it simpler than ever
> > in that regard because much more work is taken care of by both the
> > systemd developers and all of the projects shipping unit files.
> >
> > It has never been a minimalist distribution. Splitting packages is rare
> > compared to other distributions, and dependencies aren't made optional
> > whenever possible.
> >
>
> I disagree, it is indeed a minimalist, i only install what i want. ok, it
> can be not the most minimalist, but it is, in a good deal.
>
>
> >
> > It has also never been a distribution offering much user freedom /
> > choice compared to Gentoo and even Debian. There are very few cases
> > where there are multiple packages offering different configurations of
> > the same project. There's no equivalent to update-alternatives or the
> > comparable uses of USE flags. Changing /bin/sh from Bash will be broken,
> > as will changing the python symlink to point to python2 instead of
> > python3 even though this works on some other distributions. It doesn't
> > strive to offer choices like this, and never has. It would mean a *lot*
> > more complexity on the development side of things along with major
> > deviations from upstream.
> >
> > Arch is the *opposite* of a user-centric freedom. The opinion of users
> > has no weight here. Only the developers have an opinion, and there
> > aren't voting systems as there are in Debian. Technical decisions are
> > made based on merit via consensus among the developers, not popularity.
> >
>
> WHAT? The opinion of users has no weight here ?!?!?!
> I came to Arch because th way it is built and "marketed" looked like a real
> community and user centric, user centric not to be as easy as pushing a
> button, but in the way that i can install, configure, and use it the way i
> want to.
> Is that real?
>
> If Arch is becoming a personal distribution to attend the developers, so
> let it clrealy in the website, so we consider choosing a new way.
> But to realize such an affirmation is a little bit dismotivating at
> minimum.
>
> Although this subject, i wanna thanks the devs; because everyone knows it a
> hard work and Arch devs always did a great work.
>
> The real POINT here is that, ANY decision made (not only systemd) have its
> pros and cons, but when someone ask for something different or question
> that, it is wise to listen, think, and answer in an polite way.
> Recently i am seeing much rage in talks, i think i will be better, and
> constructive, to filter better the words so that we can have a kind of a
> talk.
>
>
>
> > > it is not simple, not minimalist, and not us

Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Eduardo Machado
2015-07-02 10:24 GMT-03:00 Daniel Micay :

> On 01/07/15 02:36 PM, João Miguel wrote:
> > First of all, thank you for such a quick reply.
> >
> > Now, I don't want to preach. But I will not pretend I chose Arch Linux at
> > random. I chose it for many reasons, an important one of them being that
> > I liked the Arch Way, it made sense to me, and it seemed you were
> > following it. Now it seems to belong to a forgotten past.
> >
> > On Wed, Jul 01, 2015 at 10:34:01AM -0400, Daniel Micay wrote:
> >> Arch is as much a systemd-based distribution as it is a Pacman-based
> >> distribution at this point. (...)
> > Is it now? https://wiki.archlinux.org/index.php/The_Arch_Way
>
> That's an unprotected page on the wiki, not an authoritative source on
> anything to do with the distribution.
>
> Arch has always been a simple distribution in terms of the developer
> perspective, not the user one. Using systemd made it simpler than ever
> in that regard because much more work is taken care of by both the
> systemd developers and all of the projects shipping unit files.
>
> It has never been a minimalist distribution. Splitting packages is rare
> compared to other distributions, and dependencies aren't made optional
> whenever possible.
>

I disagree, it is indeed a minimalist, i only install what i want. ok, it
can be not the most minimalist, but it is, in a good deal.


>
> It has also never been a distribution offering much user freedom /
> choice compared to Gentoo and even Debian. There are very few cases
> where there are multiple packages offering different configurations of
> the same project. There's no equivalent to update-alternatives or the
> comparable uses of USE flags. Changing /bin/sh from Bash will be broken,
> as will changing the python symlink to point to python2 instead of
> python3 even though this works on some other distributions. It doesn't
> strive to offer choices like this, and never has. It would mean a *lot*
> more complexity on the development side of things along with major
> deviations from upstream.
>
> Arch is the *opposite* of a user-centric freedom. The opinion of users
> has no weight here. Only the developers have an opinion, and there
> aren't voting systems as there are in Debian. Technical decisions are
> made based on merit via consensus among the developers, not popularity.
>

WHAT? The opinion of users has no weight here ?!?!?!
I came to Arch because th way it is built and "marketed" looked like a real
community and user centric, user centric not to be as easy as pushing a
button, but in the way that i can install, configure, and use it the way i
want to.
Is that real?

If Arch is becoming a personal distribution to attend the developers, so
let it clrealy in the website, so we consider choosing a new way.
But to realize such an affirmation is a little bit dismotivating at minimum.

Although this subject, i wanna thanks the devs; because everyone knows it a
hard work and Arch devs always did a great work.

The real POINT here is that, ANY decision made (not only systemd) have its
pros and cons, but when someone ask for something different or question
that, it is wise to listen, think, and answer in an polite way.
Recently i am seeing much rage in talks, i think i will be better, and
constructive, to filter better the words so that we can have a kind of a
talk.



> > it is not simple, not minimalist, and not user-centric.
>
> Certainly not minimalist, but those other two claims are questionable.
>
> Arch has *never* been minimalist... a Linux kernel with every module
> available and every feature enabled at least when there's no non-bloat
> related cost, feature-packed/complex GNU tools, nearly all optional
> features enabled across all the packages, etc.
>
> > However, making so many packages depend on it so that any basic desktop
> > usage (in the case of the util-linux dependency, even non-graphical
> usage)
> > does break one principle listed in the aforementioned page: freedom. In
> > fact, I ought to quote it:
>
> Arch is the opposite of a distribution with lots of user freedom. Users
> will come and go based on whether they like the technical decisions made
> by the developers. The popularily of those decisions has no impact on
> how things are done, regardless of how vocal users are about it.
>
> > Nonetheless, respecting the quoted principle, I could easily replace
> > systemd by OpenRC when I chose to. Note that just last month, over 3
> > years had passed after systemd was adopted, and I could still use
> > OpenRC. Now, for whatever reason, the principle was broken without
> > notice. I'd expect news or an email in this mailing list, to which I've
> > been paying close attention (though I knew less than the authors about
> > most problems...).
>
> You can still use it, it's just becoming increasing more difficult at a
> pretty steady pace. Those packages didn't suddenly pick up systemd
> dependencies in the past few weeks / months anyway. The version control
> logs

Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Neven Sajko
Daniel Micay dixit:
>The package isn't going to be split so it doesn't make much sense to
>refer to libsystemd.

It is split:
https://www.archlinux.org/packages/core/x86_64/libsystemd/


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Olivier Langlois
On Thu, 2015-07-02 at 09:24 -0400, Daniel Micay wrote:
> On 01/07/15 02:36 PM, João Miguel wrote:
> > First of all, thank you for such a quick reply.
> > 
> > Now, I don't want to preach. But I will not pretend I chose Arch 
> > Linux at
> > random. I chose it for many reasons, an important one of them being 
> > that
> > I liked the Arch Way, it made sense to me, and it seemed you were
> > following it. Now it seems to belong to a forgotten past.
> > 
> > On Wed, Jul 01, 2015 at 10:34:01AM -0400, Daniel Micay wrote:
> > > Arch is as much a systemd-based distribution as it is a Pacman
> > > -based
> > > distribution at this point. (...)
> > Is it now? https://wiki.archlinux.org/index.php/The_Arch_Way
> 
> That's an unprotected page on the wiki, not an authoritative source 
> on
> anything to do with the distribution.
> 
> Arch has always been a simple distribution in terms of the developer
> perspective, not the user one. Using systemd made it simpler than 
> ever
> in that regard because much more work is taken care of by both the
> systemd developers and all of the projects shipping unit files.
> 
> It has never been a minimalist distribution. Splitting packages is 
> rare
> compared to other distributions, and dependencies aren't made 
> optional
> whenever possible.
> 
It seems these types of discussion pops out once in a while.
Personally, I think that systemd has a lot qualities. The only thing
that I do not like about it it is that does not follow the UNIX
philosophy. Philosophy that has made UNIX/Linux so successful for so
many years. Read The Art of UNIX Programming from Eric Raymond to know
what that philosophy really is.

That being said, no one can really complain given that you receive what
you have paid for. I understand that very influent people among the
Arch dev community are also major contributors of systemd so it is
quite natural that ArchLinux is a systemd based dist.

Red Hat has interests in systemd success. Who can blame an organisation
trying to dominate and success? It is the nature of the beast...

As a user, despite not having easy alternatives if I wanted to switch
to a different init system, ArchLinux still provide the best Linux
experience that I ever had!

> 


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Eli Schwartz
Arch officially does not support alternative init systems. Therefore, there
is no reason to expect that the official repos will go out of their way to
help you do so.
There is an underlying assumption that any Arch system uses systemd.

Any AUR package is responsible for depending on other AUR packages, if
using the main repo packages breaks things.


-- Eli Schwartz


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Ralf Mardorf
On Thu, 2 Jul 2015 09:24:42 -0400, Daniel Micay wrote:
>Arch is the *opposite* of a user-centric freedom.

I disagree.

>> it is not simple, not minimalist, and not user-centric.  
>
>Certainly not minimalist, but those other two claims are questionable.

I agree.

Reasoning:

With everything Arch provides regarding it's policy, it's following the
KISS principle. Since software from upstream usually is not split into
tons of packages, it might be not minimalist, but even this could be
handled, since pacman.conf provides the NoExtract option. Assumed a
package comes with an unneeded dependency, it's easy to provide an
empty dummy package to resolve this unneeded dependency. There's no
need to compile it from ABS with special configure options, assumed the
dependency is really unneeded.

The user centric-freedom still is, that we users could make our
individual installs, the way we like it, without much pain, by e.g.
providing outdated libs and resolving unneeded dependencies.

I'm not in favour of systemd, but for me the drawbacks caused by
systemd are still big nothing compared to the advantages provided by
Arch Linux, IOW I like the KISS principle policy and the user-centric
policy.

The fight against systemd was lost a long time ago. We can live with
systemd or use another distro, period. If we are using Arch with
systemd and run into issues, we are free to send requests to this list
or a forum.

IMO we shouldn't continue another Arch systemd policy thread, since we
finished this discussion a long, long time ago.

Regards,
Ralf


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Daniel Micay
On 01/07/15 07:14 PM, Jens Adam wrote:
> Thu, 2 Jul 2015 00:43:13 +0200
> Guus Snijders :
> 
>>> Why in the world should util-linux require systemd!? Why do all
>>> these packages need it when they were fine without it before?  
>>
>> The first question is a relatively simple, technical question. My
>> guess is that the util-linux won't currently run without system
>> installed, hence the dependancy. Arch packages are usually quite
>> 'clean' in that respect. It's probably possible to recompile it
>> without that dependency for this specific case.
> 
> A little fiddling with 'pacman -Qql util-linux' and 'ldd' reveals that
> the only tools linked to (lib)systemd are 'logger', 'lslogins' and
> 'uuidd'.

So it's a hard runtime dependency for a core tool that's widely used
(logger). Making it into an optional dependency would cause runtime
crashes and it would be especially bad in this case because other
packages depend on util-linux for utilities like logger.

Splitting it out into another package would be the Debian solution, but
Arch avoids that to avoid complexity. Gentoo handles this with USE flags.

> Aside from that: Yes, some packages do have too broad dependencies
> (e.g. systemd instead of libsystemd) and it certainly didn't help
> that udev became part of systemd, but in the end the train we're on
> drove off long ago, so until systemd's successor arrives on the scene
> it's probably best to accustom yourself to it and test it until all
> the bugs and edge cases are accounted for.

The package isn't going to be split so it doesn't make much sense to
refer to libsystemd. It's considered part of the mandatory base system
and the developers aren't going to go out of the way to make it optional
by adding this kind of complexity on their end.w



signature.asc
Description: OpenPGP digital signature


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Damjan Georgievski
> Arch has always been a simple distribution in terms of the developer
> perspective, not the user one. Using systemd made it simpler than ever
> in that regard because much more work is taken care of by both the
> systemd developers and all of the projects shipping unit files.

I find systemd easier from an user perspective too. Or ok, let say, a
sys-admin one.
And I'm talking from my >14 years profesional Linux experience. Wow,
has it been so long.
18 years since I first installed Linux (Slackware 3, Debian 2.2,
RedHat, Mandrake, Slackware, Arch
- now using Arch for my laptop/desktop, Debian and Ubuntu on servers,
sometimes Centos/RHEL).


And I can hardly wait for distros to standardize on networkd too. Finally some
long needed standardization in the basic setup of a Linux system.



-- 
damjan


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-02 Thread Daniel Micay
On 01/07/15 02:36 PM, João Miguel wrote:
> First of all, thank you for such a quick reply.
> 
> Now, I don't want to preach. But I will not pretend I chose Arch Linux at
> random. I chose it for many reasons, an important one of them being that
> I liked the Arch Way, it made sense to me, and it seemed you were
> following it. Now it seems to belong to a forgotten past.
> 
> On Wed, Jul 01, 2015 at 10:34:01AM -0400, Daniel Micay wrote:
>> Arch is as much a systemd-based distribution as it is a Pacman-based
>> distribution at this point. (...)
> Is it now? https://wiki.archlinux.org/index.php/The_Arch_Way

That's an unprotected page on the wiki, not an authoritative source on
anything to do with the distribution.

Arch has always been a simple distribution in terms of the developer
perspective, not the user one. Using systemd made it simpler than ever
in that regard because much more work is taken care of by both the
systemd developers and all of the projects shipping unit files.

It has never been a minimalist distribution. Splitting packages is rare
compared to other distributions, and dependencies aren't made optional
whenever possible.

It has also never been a distribution offering much user freedom /
choice compared to Gentoo and even Debian. There are very few cases
where there are multiple packages offering different configurations of
the same project. There's no equivalent to update-alternatives or the
comparable uses of USE flags. Changing /bin/sh from Bash will be broken,
as will changing the python symlink to point to python2 instead of
python3 even though this works on some other distributions. It doesn't
strive to offer choices like this, and never has. It would mean a *lot*
more complexity on the development side of things along with major
deviations from upstream.

Arch is the *opposite* of a user-centric freedom. The opinion of users
has no weight here. Only the developers have an opinion, and there
aren't voting systems as there are in Debian. Technical decisions are
made based on merit via consensus among the developers, not popularity.


> it is not simple, not minimalist, and not user-centric.

Certainly not minimalist, but those other two claims are questionable.

Arch has *never* been minimalist... a Linux kernel with every module
available and every feature enabled at least when there's no non-bloat
related cost, feature-packed/complex GNU tools, nearly all optional
features enabled across all the packages, etc.

> However, making so many packages depend on it so that any basic desktop
> usage (in the case of the util-linux dependency, even non-graphical usage)
> does break one principle listed in the aforementioned page: freedom. In
> fact, I ought to quote it:

Arch is the opposite of a distribution with lots of user freedom. Users
will come and go based on whether they like the technical decisions made
by the developers. The popularily of those decisions has no impact on
how things are done, regardless of how vocal users are about it.

> Nonetheless, respecting the quoted principle, I could easily replace
> systemd by OpenRC when I chose to. Note that just last month, over 3
> years had passed after systemd was adopted, and I could still use
> OpenRC. Now, for whatever reason, the principle was broken without
> notice. I'd expect news or an email in this mailing list, to which I've
> been paying close attention (though I knew less than the authors about
> most problems...).

You can still use it, it's just becoming increasing more difficult at a
pretty steady pace. Those packages didn't suddenly pick up systemd
dependencies in the past few weeks / months anyway. The version control
logs disprove the claim that there are many recent changes.

>> Upstreams are integrating support for systemd features and Arch is going
>> to be enabling them, whether it's sd_notify support or something else.
> Upstream? Then why is it that for the same versions of the same
> packages, say, in Gentoo they are not dependencies? Example, compare
> these two:

Gentoo has USE flags so features can be optional at compile-time. Many
of the packages with dependencies on systemd in Arch link against
libsystemd, and we don't split up the package as is the norm here. If
there's a package with an *unnecessary* dependency on systemd, you can
and should file a bug. I don't think there are many that depend on it
and don't use it.

> That doesn't mean I want to compile everything. Or that you should have
> packages for, say, OpenRC. The packages in the repos are not my choice,
> I'm not asking to choose which ones should be on the official repos,
> that's what the unofficial repos and the AUR are for. It just means you
> shouldn't suppose people have these or those packages installed, but
> that instead, and as you did before, even years after systemd being
> default, you should provide whatever you want, open the doors you want,
> not closing any others. Minimalism means minimal dependencies too.


> If I wanted sy

Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-01 Thread Jan Alexander Steffens
On Wed, Jul 1, 2015 at 3:52 PM,   wrote:
> However, in the latest update it seems an awful lot of packages I use
> suddenly require systemd. First, I have a conflict between libgudev and
> eudev-systemdcompat, so the installation stops right there. I don't even
> remember a libgudev package when I used systemd! The pacman output, 1st
> refusing to remove eudev, then accepting, is as follows:

libgudev was split from systemd into its own project. As a result,
some packages have picked up a dependency on libgudev. However,
libgudev cannot be installed on your system because it conflicts with
eudev.

To clear up your dependencies, try having whatever eudev package
contains libgudev.so provide libgudev.


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-01 Thread Jens Adam
Thu, 2 Jul 2015 00:43:13 +0200
Guus Snijders :

> > Why in the world should util-linux require systemd!? Why do all
> > these packages need it when they were fine without it before?  
> 
> The first question is a relatively simple, technical question. My
> guess is that the util-linux won't currently run without system
> installed, hence the dependancy. Arch packages are usually quite
> 'clean' in that respect. It's probably possible to recompile it
> without that dependency for this specific case.

A little fiddling with 'pacman -Qql util-linux' and 'ldd' reveals that
the only tools linked to (lib)systemd are 'logger', 'lslogins' and
'uuidd'.

Aside from that: Yes, some packages do have too broad dependencies
(e.g. systemd instead of libsystemd) and it certainly didn't help
that udev became part of systemd, but in the end the train we're on
drove off long ago, so until systemd's successor arrives on the scene
it's probably best to accustom yourself to it and test it until all
the bugs and edge cases are accounted for.

--byte


pgpJjp84D5lrQ.pgp
Description: Digitale Signatur von OpenPGP


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-01 Thread Guus Snijders
Op 1 jul. 2015 15:52 schreef :
>
> Hi there,
>
> Not sure whether I should email this mailing list about this problem,
> but here goes:
>
> I've been using OpenRC in Arch Linux for a long time, and uninstalled
> systemd, as I don't use anything that requires it.
>
[snip]
>
>
> Why in the world should util-linux require systemd!? Why do all these
> packages need it when they were fine without it before?

The first question is a relatively simple, technical question. My guess is
that the util-linux won't currently run without system installed, hence the
dependancy. Arch packages are usually quite 'clean' in that respect.
It's probably possible to recompile it without that dependency for this
specific  case.

The second question is a bit broad and calls for advocacy and that has
it's  effect. Too bad, since these kind of threads usually lead to some
(pointlessly long) debates without any real outcome...

Next time, try to stick to the technical questions and perhaps the replies
are more helpful and less frustrating.

Just my $0,02

Mvg, Guus


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-01 Thread David Kaylor
Actually there are 2 actively maintained implementations of openrc for arch
:

> Apg way (uses udev from systemd but everything else is openrc) and artoo
> way (can be used with eudev) .
>
> Users of both variants communicate through this forum thread :
> https://bbs.archlinux.org/viewtopic.php?id=152606
>
> LVV
>

That's wonderful; but it doesn't invalidate what I stated earlier. Direct
your comments to the OP.


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-01 Thread LoneVVolf

On 01-07-15 21:12, David Kaylor wrote:

I rest my case. Again, any reply is welcome.


You are wasting your keystrokes and your time.

Arch devs have long since decided to make systemd an integral part of Arch
Linux. And I didn't like it any more than you do, at first.
Actually there are 2 actively maintained implementations of openrc for 
arch :
Apg way (uses udev from systemd but everything else is openrc) and artoo 
way (can be used with eudev) .


Users of both variants communicate through this forum thread :
https://bbs.archlinux.org/viewtopic.php?id=152606

LVV


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-01 Thread David Kaylor
> I rest my case. Again, any reply is welcome.
>

You are wasting your keystrokes and your time.

Arch devs have long since decided to make systemd an integral part of Arch
Linux. And I didn't like it any more than you do, at first.


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-01 Thread Florian Pritz
On Wed, 1 Jul 2015 19:36:07 +0100 João Miguel 
wrote:
> Nonetheless, respecting the quoted principle, I could easily replace
> systemd by OpenRC when I chose to. Note that just last month, over 3
> years had passed after systemd was adopted, and I could still use
> OpenRC. Now, for whatever reason, the principle was broken without
> notice. I'd expect news or an email in this mailing list, to which I've
> been paying close attention (though I knew less than the authors about
> most problems...).

Feels like this post[1] by Adam Jackson fits perfectly. Calling for
freedom or choice is not going to help anyone.

[1]
https://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html

Maintaining a distro is hard, takes a lot of time and effort and nobody
here is payed for their work on Arch. If you have problems
please talk about those problems, not about workarounds that break. We
might be able to resolve actual issues, but to do that we need to know
what is broken, not how you work around that breakage.

> > Upstreams are integrating support for systemd features and Arch is going
> > to be enabling them, whether it's sd_notify support or something else.
> Upstream? Then why is it that for the same versions of the same
> packages, say, in Gentoo they are not dependencies? Example, compare
> these two:
> 
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-drivers/xf86-input-evdev/xf86-input-evdev-2.9.2.ebuild
> https://www.archlinux.org/packages/extra/x86_64/xf86-input-evdev/

If you believe this dependency is wrong create a bug report or talk to
the maintainer and find out why they think it is necessary. If it turns
out it's incorrect I'm sure it will be removed.


pgpk7f1Ipqf6b.pgp
Description: OpenPGP digital signature


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-01 Thread João Miguel
First of all, thank you for such a quick reply.

Now, I don't want to preach. But I will not pretend I chose Arch Linux at
random. I chose it for many reasons, an important one of them being that
I liked the Arch Way, it made sense to me, and it seemed you were
following it. Now it seems to belong to a forgotten past.

On Wed, Jul 01, 2015 at 10:34:01AM -0400, Daniel Micay wrote:
> Arch is as much a systemd-based distribution as it is a Pacman-based
> distribution at this point. (...)
Is it now? https://wiki.archlinux.org/index.php/The_Arch_Way says
different. systemd is the opposite of the Arch Way except for being
open-source: it is not simple, not minimalist, and not user-centric.

But that is not really what this problem is about. Although it is a bit
mind-boggling that systemd has been chosen as the main init system for
Arch, its shortcomings are not necessarily shortcomings of Arch. That
is, Arch can still be simple, minimalist, etc. and it is with the
conscience of this fact that I chose to install Arch Linux in all my
systems. systemd breaks the Arch Way. Having it as a package doesn't.

However, making so many packages depend on it so that any basic desktop
usage (in the case of the util-linux dependency, even non-graphical usage)
does break one principle listed in the aforementioned page: freedom. In
fact, I ought to quote it:

Another guiding principle of Arch Linux development is freedom. Users
are not only permitted to make all decisions concerning system
configuration, but also choose what their system will be.

By keeping the system simple, Arch Linux provides the freedom to make
any choice about the system.

A freshly installed Arch Linux system contains only basic core
components with no automatic configuration performed. Users are able to
configure the system as they wish, from the shell. From the start of the
installation procedure, every component of the system is 100%
transparent and accessible for instant access, removal, or replacement
by alternative components.

The large number of packages and build scripts in the various Arch Linux
repositories also support freedom of choice, offering free and open
source software for those who prefer it, as well as proprietary software
packages, for those who embrace functionality over ideology. It is the
user who chooses.

As Judd Vinet, the founder of the Arch Linux project said: "[Arch Linux]
is what you make it."

I used systemd in Arch for a long time. In fact, when I came, it was
already the main init system, and I didn't really mind, or know much
about it.

Nonetheless, respecting the quoted principle, I could easily replace
systemd by OpenRC when I chose to. Note that just last month, over 3
years had passed after systemd was adopted, and I could still use
OpenRC. Now, for whatever reason, the principle was broken without
notice. I'd expect news or an email in this mailing list, to which I've
been paying close attention (though I knew less than the authors about
most problems...).

> Upstreams are integrating support for systemd features and Arch is going
> to be enabling them, whether it's sd_notify support or something else.
Upstream? Then why is it that for the same versions of the same
packages, say, in Gentoo they are not dependencies? Example, compare
these two:

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-drivers/xf86-input-evdev/xf86-input-evdev-2.9.2.ebuild
https://www.archlinux.org/packages/extra/x86_64/xf86-input-evdev/

That doesn't mean I want to compile everything. Or that you should have
packages for, say, OpenRC. The packages in the repos are not my choice,
I'm not asking to choose which ones should be on the official repos,
that's what the unofficial repos and the AUR are for. It just means you
shouldn't suppose people have these or those packages installed, but
that instead, and as you did before, even years after systemd being
default, you should provide whatever you want, open the doors you want,
not closing any others. Minimalism means minimal dependencies too.

If I wanted systemd bloat and a dash of hypocrisy, I'd stay in Windows
installing Internet Explorer... I worry the suggestions to change distro
are going too far. The point is not one of telling what the devs should
or shouldn't do, but of remembering the principles upon which the
community is based.

I rest my case. Again, any reply is welcome.
João Miguel


Re: [arch-general] systemd new dependencies impede using OpenRC

2015-07-01 Thread Daniel Micay
On 01/07/15 09:52 AM, jmcf...@openmailbox.org wrote:

> Why in the world should util-linux require systemd!? Why do all these
> packages need it when they were fine without it before? I wouldn't like
> to install systemd, but will if necessary. Nonetheless, I don't want it
> to replace OpenRC. What can I do? I want an updated system, but I'd very
> much prefer to have one without systemd

Arch is as much a systemd-based distribution as it is a Pacman-based
distribution at this point. The best options you have available are
switching to a distribution with official support for at least one other
init system without any of systemd installed (Gentoo, Alpine, Slackware,
[...]) or just accepting that Arch is a systemd distribution and
switching to it.

There *are* systemd-based distributions like Debian that aren't (yet)
fully dropping support for other init systems, but Arch never intended
to preserve support for other options when it switched. Debian also
splits systemd into many packages and has various stubs for running
stuff that depends on it without all of it running / installed. It
sounds like you'd be happiest using a distribution where no systemd
components are ever going to be required though, and there are plenty.

Upstreams are integrating support for systemd features and Arch is going
to be enabling them, whether it's sd_notify support or something else.
Packages aren't going to go out of the way to support a niche,
unsupported use case. It's only going to get more painful to swim
against the current as time goes on. The various dbus client
implementations will probably be switched over to using kdbus this year,
for one thing. I'm sure there will be more.



signature.asc
Description: OpenPGP digital signature