| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 51:41:08 |
| Calls: | 422 |
| Files: | 1,025 |
| Messages: | 90,554 |
[What's the proxy-maint thing that the QAreport complains? Plz, IDK
what it is.]
Why can't I use "${PV}" "${PN}" in the HOMEPAGE= ? Without those
variables in there I'd have to update them on *every* version
upgrade.
The bot(s) also link to
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers/User_Guide
If you are not a Gentoo Developer, you need a Gentoo Developer to merge changes for you. This is called proxying -- you author the change and
someone else helps you by merging it.
The Proxy Maintainers project is a team of Gentoo Developers that devote their time to helping proxy most people who ask, depending on
availability. There are some guidelines around when Proxy-Maintainers is willing to take on new packages.
You can also arrange privately with a specific Gentoo Developer to have
them proxy you, without the involvement of the Proxy-Maintainers team
effort.
Why can't I use "${PV}" "${PN}" in the HOMEPAGE= ? Without those
variables in there I'd have to update them on every version
upgrade.
The purpose of HOMEPAGE is, in part, that it is easy to copy/paste from
the file without executing it in a bash shell.
Please report a critical upstream bug if there is no generic homepage
for the project that can be used without a constantly changing version number. Even if the only project information is a generated
documentation page, it is standard operating procedure for software to
have a documentation site where {site}/latest/ is the docs for the
current version, and {site}/1.0.0/ is the docs for a specific version.
dbus-broker depends on systemd, and you probably don't want 66 to
pull in systemd. :-)
i don't understand why you're talking about elog in the context of
D-Bus. Could you please elaborate?
(My experience is that people regularly fail to distinguish
between a D-Bus system bus - provided by the `dbus` service -
and a D-Bus session bus; each has its own purpose.)
https://archives.gentoo.org/gentoo-user/87cyeb2gxs.fsf@gmail.com/
although i see that Eli has written an overview of the topic in
his reply to you.
dbus-broker depends on systemd, and you probably don't want 66
to
pull in systemd. :-)
Only with the USE=launcher
`66-dbus-launch` in `sys-apps/66-tools` provides an alternative
"launcher" which doesn't depend on systemd. It instead uses 66.
This page says that 66-dbus-launch actually starts dbus-broker,
which, as i said, depends on systemd:
https://web.obarun.org/software/66-tools/0.1.1.0/66-dbus-launch/
although i acknowledge that page might be out-of-date.
If it's not, what you'll need in this context is something that
calls dbus-daemon(1), which doesn't depend on
systemd. dbus-run-session(1), dbus-launch(1), and the `dbus`
OpenRC service all use dbus-daemon(1).
I am asking whether to inform users via `elog "blah blah"` in
the
ebuild. I have decided to do so.
Inform users of what?
Firstly, as some context, i'm the author of a guide "D-Bus: The
essentials":
https://github.com/flexibeast/guides/blob/master/dbus.md
and a guide "D-Bus and X sessions":
https://github.com/flexibeast/guides/blob/master/dbus-and-x-sessions.md
as well as having made various edits related to D-Bus on the
Gentoo wiki.
i'm also the person who ported the documentation for various
skaware packages to man pages:
https://wiki.gentoo.org/wiki/User:Flexibeast#The_s6_ecosystem
and have written a guide on using s6 and s6-rc for user services
under OpenRC:
https://wiki.gentoo.org/wiki/User:Flexibeast/guides/OpenRC_user_services_via_s6_and_s6-rc
My point is that, regardless of dbus-broker's advantages over
dbus-daemon, it depends on systemd: anything that needs to
install the `dbus-broker` package will result in the `systemd`
package being installed as well, even if systemd isn't being
directly used for init / service supervision / service management
(which are distinct things). i'm using OpenRC with
sys-apps/systemd masked:
```
# emerge dbus-broker
Local copy of remote index is up-to-date and will be used.
Local copy of remote index is up-to-date and will be used.
Calculating dependencies... done!
Dependency resolution took 21.84 s (backtrack: 4/20).
!!! All ebuilds that could satisfy ">=sys-apps/systemd-230:0="
have been masked.
!!! One of the following masked packages is required to complete
your request:
- sys-apps/systemd-9999::gentoo (masked by: package.mask, missing
keyword)
- sys-apps/systemd-257.3::gentoo (masked by: package.mask, ~amd64
keyword)
- sys-apps/systemd-256.12::gentoo (masked by: package.mask, ~amd64
keyword)
- sys-apps/systemd-256.10::gentoo (masked by: package.mask)
- sys-apps/systemd-254.24::gentoo (masked by: package.mask, ~amd64
keyword)
- sys-apps/systemd-254.22::gentoo (masked by: package.mask)
(dependency required by
"sys-apps/dbus-broker-36::gentoo[launcher]" [ebuild])
(dependency required by "dbus-broker" [argument])
```
Having systemd installed will be the opposite of what many - if
not most! - people wanting to use 66 will want. "So in order to
use this alternative to systemd .... I'll need systemd
installed???" And if you need an idea of how strongly people not
wanting to use systemd can feel around this stuff, search the
Gentoo forums for people complaining about the systemd-utils
package getting installed on their non-systemd systems;
cf. e.g. https://forums.gentoo.org/viewtopic-t-1169990-start-0.html.
My advice and suggestions are based on my knowledge and
experiences in this area, with the intention of helping you create
a package that people will want to use. But also, i don't want
people to get the impression that 66 depends on systemd - which it
doesn't - simply because you insist on using dbus-broker rather
than dbus-daemon, even though the latter is perfectly adequate for
most people's needs (including my own).
Pramod V U <pramodvu1502@proton.me> writes:
But this SUPPORTS broker without systemd. THE "launcher" USEFLAG...
Yes, dbus-daemon is sufficient, but I'd like to give the choice for
those who want it.
I repat once again, USE=-launcher will kill off systemd on that
package. Read the output
carefully. "sys-apps/dbus-broker-36::gentoo[launcher]" (Notice
"[launcher]"; disable it)
You are right, i was wrong - sorry. i was confused by what you had
written previously, as in your previous messages, you didn't simply write:
By setting USE=-launcher for dbus-broker, systemd doesn't get pulled in.
i'm finding it difficult to understand the points you're making, as this
and my previous question about your mention of `elog` shows, so i'll bow
out of this thread. However, regarding:
My advice and suggestions are based on my knowledge and experiences in
this area, with the intention of helping you create a package that
people will want to use. But also, i don't want people to get the
impression that 66 depends on systemd - which it doesn't - simply
because you insist on using dbus-broker rather than dbus-daemon, even
though the latter is perfectly adequate for most people's needs
(including my own).
You are right, i was wrong - sorry. i was confused by what you had
written previously, as in your previous messages, you didn't
simply write:
By setting USE=-launcher for dbus-broker, systemd doesn't get
pulled in.
i'm finding it difficult to understand the points you're making,
as this and my previous question about your mention of `elog`
shows, so i'll bow out of this thread. However, regarding:
Would you like to write a guide on using s6 and s6-rc as the
system and user init system?
Probably not, because i'm already snowed under with volunteer ICT
commitments and providing support to disabled loved ones, in
addition to having chronic health issues myself - all of which
probably contributes to me not parsing what i'm reading properly,
indicating to me that i need to step away more generally. ICT
volunteer burnout is a real thing.
That said, even though you quite correctly noted that i wasn't
paying sufficiently close attention to what you wrote, i note your
(sometimes combative) interactions with Gentoo devs elsewhere (who
are also sometimes having difficulty understanding you), and that
you yourself are not necessarily taking on board what myself and
others are saying (e.g. about proxy maint, and GURU). So just as
this interaction has made me pause and reflect on what i'm doing,
i'd like to suggest that you might want to consider doing the
same.
I am not sure I understand the proposal either, tbh.
Although in general, the job of an ebuild tends to be to ensure that mandatory requirements are satisfied somehow, so if 66 needs a launcher
and provides its own (?) then adding a dependency on an external one
seems an odd choice.
So too, depending on the absence of a USE flag, e.g.
RDEPEND="
sys-apps/dbus-broker[-launcher]
"
would unnecessarily constrain people from attempting to build it by
default without flag fiddling, whether they want systemd installed at
the same time or not. But simply having
RDEPEND="
sys-apps/dbus-broker
"
would leave it to the user to decide whether to add -launcher to
package.use, and admittedly also confuse them terribly and maybe make
them upset to see systemd being pulled in by default.
I don't know that there's a good choice here short of having a s6-66
option in `eselect profile` that adds a profile package.use which
defaults "launcher" to off.
So, avoiding dbus-broker altogether seems like the best option.
Alexis, you said before
My advice and suggestions are based on my knowledge and experiences in
this area, with the intention of helping you create a package that
people will want to use. But also, i don't want people to get the impression that 66 depends on systemd - which it doesn't - simply
because you insist on using dbus-broker rather than dbus-daemon, even though the latter is perfectly adequate for most people's needs
(including my own).
and I think I very much agree with you here. If people really want to
use dbus-broker, let them, but don't try to make portage install it for
them as it will simply cause no end of trouble.