Re: [gentoo-dev] Last rites: app-text/epdfview
Hi, "Andreas K. Huettel" writes: > # Andreas K. Huettel (7 Aug 2012) > # Many display bugs and compatibility problems, does not build with cups-1.6. > # Upstream is dead. There's no real way to support this anymore. Masked for > # removal in 30 days. > app-text/epdfview I remember when xpdf was removed, epdfview was recommended as a lightweight alternative. How about this time? Best, Benda pgp20yldw1oEV.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-dev-announce] Last rites: app-text/epdfview
Am Dienstag 07 August 2012, 00:28:16 schrieb Andreas K. Huettel: > # Andreas K. Huettel (7 Aug 2012) > # Many display bugs and compatibility problems, does not build with > cups-1.6. # Upstream is dead. There's no real way to support this anymore. > Masked for # removal in 30 days. > app-text/epdfview Improved message: # Andreas K. Huettel (7 Aug 2012) # Many display bugs and compatibility problems, does not build with cups-1.6. # Upstream is dead. There's no real way to support this anymore. Masked for # removal in 30 days. Unfortunately the best lightweight replacement I can # recommend is app-text/apvlv, otherwise you can go for app-text/acroread # (huge, closed source), kde-base/okular (KDE), or app-text/evince (Gnome). app-text/epdfview -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: app-text/epdfview
# Andreas K. Huettel (7 Aug 2012) # Many display bugs and compatibility problems, does not build with cups-1.6. # Upstream is dead. There's no real way to support this anymore. Masked for # removal in 30 days. app-text/epdfview -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
[gentoo-dev] eutils.eclass / EPATCH_EXCLUDE defined wrong?
I was goofing around trying to get current dev-vcs/git- building by skipping the CVS patch ( which is applied with epatch ) and I had a bizzare amount of time working out how to get it working. Looking at the source of eutils.eclass ' # Let people filter things dynamically ' suggests to me that this field is for use by a end user via package.env and friends. However, every time I ran emerge, the 'environment' file simply suggests that EPATCH_EXCLUDE was ="" . Looking elsewhere in eutils.eclass, I spied a forced initialization of EPATCH_EXCLUDE, which implicitly means you can't actually use this to exclude patches outside .ebuild Commenting this line out, yielded the result I had been expecting, the CVS patch being skipped . I only thought I could do this because I used something like this once upon a time with net-im/psi- and thought it was just "normal" to be able to disable patches if I really wanted to. ( But I see now they acheive this by copying MY_EPATCH_EXCLUDE to EPATCH_EXCLUDE in the .ebuild ). So, is this variable guarded against user tampering intentionally? It sure beats hacking the ebuild. ( Side note, what would also be nice is some sort of warning if things you set in package.env are getting totally ignored. But thats a hard problem ) -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On 06-08-2012 11:40:57 -0700, Olivier Crête wrote: > I think they only want to support systemd-in-systemd, not > systemd-in-random-init-system. I think neither fits Prefix. So we're back at the starting position. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, 2012-08-06 at 20:28 +0200, Fabian Groffen wrote: > On 06-08-2012 11:16:52 -0700, Olivier Crête wrote: > > On Mon, 2012-08-06 at 13:56 +0200, Fabian Groffen wrote: > > > While OpenRC is likely perfectly capable of starting/stopping daemons as > > > a normal user (with some tweaks), I expect systemd replacing init, to > > > already have a fair bit of isssues with being just a normal unprivileged > > > user. I may be wrong, of course. However, the notorious reputation of > > > that piece of software aiming for system-domination doesn't really make > > > it sound to me like it ever will be a good match for Prefix. > > > > You happen to be wrong. systemd runs perfectly as non-pid-1. Part of > > Lennart's well published plan for world domination is to use systemd as > > a session manager, so it would replace gnome-session, etc. Lennart & > > friends are currently pushing kernel patches to make it fully recursive > > (such as being able to re-parent orphaned processes to the session's > > systemd instead of the global one. > > Good to know that I'm wrong. I didn't know they pursued world > domination too. I wonder how "kernel patches" go well together with > "being in an environment unknown to you, or that you cannot control at > all", though. Seems there is interest for it to support Prefix then. > Looking forward to patches and solutions to complement the challenges of > this year's GSoC task. I think they only want to support systemd-in-systemd, not systemd-in-random-init-system. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On 06-08-2012 11:16:52 -0700, Olivier Crête wrote: > On Mon, 2012-08-06 at 13:56 +0200, Fabian Groffen wrote: > > While OpenRC is likely perfectly capable of starting/stopping daemons as > > a normal user (with some tweaks), I expect systemd replacing init, to > > already have a fair bit of isssues with being just a normal unprivileged > > user. I may be wrong, of course. However, the notorious reputation of > > that piece of software aiming for system-domination doesn't really make > > it sound to me like it ever will be a good match for Prefix. > > You happen to be wrong. systemd runs perfectly as non-pid-1. Part of > Lennart's well published plan for world domination is to use systemd as > a session manager, so it would replace gnome-session, etc. Lennart & > friends are currently pushing kernel patches to make it fully recursive > (such as being able to re-parent orphaned processes to the session's > systemd instead of the global one. Good to know that I'm wrong. I didn't know they pursued world domination too. I wonder how "kernel patches" go well together with "being in an environment unknown to you, or that you cannot control at all", though. Seems there is interest for it to support Prefix then. Looking forward to patches and solutions to complement the challenges of this year's GSoC task. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, 2012-08-06 at 13:56 +0200, Fabian Groffen wrote: > While OpenRC is likely perfectly capable of starting/stopping daemons as > a normal user (with some tweaks), I expect systemd replacing init, to > already have a fair bit of isssues with being just a normal unprivileged > user. I may be wrong, of course. However, the notorious reputation of > that piece of software aiming for system-domination doesn't really make > it sound to me like it ever will be a good match for Prefix. You happen to be wrong. systemd runs perfectly as non-pid-1. Part of Lennart's well published plan for world domination is to use systemd as a session manager, so it would replace gnome-session, etc. Lennart & friends are currently pushing kernel patches to make it fully recursive (such as being able to re-parent orphaned processes to the session's systemd instead of the global one. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, 6 Aug 2012 08:05:42 -0400 Rich Freeman wrote: > On Mon, Aug 6, 2012 at 7:56 AM, Fabian Groffen > wrote: > > While OpenRC is likely perfectly capable of starting/stopping > > daemons as a normal user (with some tweaks), I expect systemd > > replacing init, to already have a fair bit of isssues with being > > just a normal unprivileged user. I may be wrong, of course. > > However, the notorious reputation of that piece of software aiming > > for system-domination doesn't really make it sound to me like it > > ever will be a good match for Prefix. > > Yup, hence my final comment. However, I suspect that the > multitude-of-init-systems is going to be a somewhat temporary > condition for a few years, and after that with the amount of vertical > integration everybody is pushing one may win out. If that happens, > we'll all be using whatever that ends up being, regardless of whether > it is a good match for Prefix. If the world remains heterogeneous > then most likely Gentoo will remain as such also, and other than all > the package maintainers having to supply 3 different init scripts for > their pacakges all will be well for Prefix. I would be really happy if openrc supported systemd units. Or any other good unit format but it's probably too late to invent anything here... -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, 6 Aug 2012 07:49:48 -0400 Rich Freeman wrote: > On Mon, Aug 6, 2012 at 6:42 AM, Fabian Groffen > wrote: > > On 06-08-2012 13:37:55 +0300, Samuli Suominen wrote: > >> > Also, I'm not so sure if this will work correctly for Prefix. > >> > >> I'm sure that is easily checked and we will get feedback quickly. > > > > I'm sure systemd/udev will never run in (a) Prefix, so perhaps it is > > more sensical not to pseudo-provide support for it. > > > > I wouldn't be so quick to make that assumption. Right now openrc > doesn't work on Prefix but there is a SoC project to change that. Why > wouldn't we assume that somebody will do the same for systemd? > Obviously the long-term future of systemd/openrc/alternatives is > unclear now, but that just seems to be all the more reason to keep our > options open. > > I'm not suggesting that we fully build-in support for systemd under > Prefix and so on, but rather I'm suggesting that if leaving it open as > an option now saves us a lot of rework later we should consider it. > > (And yes, I realize that systemd is currently linux-only and why that > would make any use under Prefix difficult.) There are Linux prefixes too, aren't there? I see one use for Prefix systemd unit files currently: when host runs systemd, and user uses (symlinks) the Gentoo Prefix init files to start prefixed services on the host. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, Aug 6, 2012 at 7:56 AM, Fabian Groffen wrote: > While OpenRC is likely perfectly capable of starting/stopping daemons as > a normal user (with some tweaks), I expect systemd replacing init, to > already have a fair bit of isssues with being just a normal unprivileged > user. I may be wrong, of course. However, the notorious reputation of > that piece of software aiming for system-domination doesn't really make > it sound to me like it ever will be a good match for Prefix. Yup, hence my final comment. However, I suspect that the multitude-of-init-systems is going to be a somewhat temporary condition for a few years, and after that with the amount of vertical integration everybody is pushing one may win out. If that happens, we'll all be using whatever that ends up being, regardless of whether it is a good match for Prefix. If the world remains heterogeneous then most likely Gentoo will remain as such also, and other than all the package maintainers having to supply 3 different init scripts for their pacakges all will be well for Prefix. Rich
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On 06-08-2012 07:49:48 -0400, Rich Freeman wrote: > On Mon, Aug 6, 2012 at 6:42 AM, Fabian Groffen wrote: > > On 06-08-2012 13:37:55 +0300, Samuli Suominen wrote: > >> > Also, I'm not so sure if this will work correctly for Prefix. > >> > >> I'm sure that is easily checked and we will get feedback quickly. > > > > I'm sure systemd/udev will never run in (a) Prefix, so perhaps it is > > more sensical not to pseudo-provide support for it. > > I wouldn't be so quick to make that assumption. Right now openrc > doesn't work on Prefix but there is a SoC project to change that. Why > wouldn't we assume that somebody will do the same for systemd? > Obviously the long-term future of systemd/openrc/alternatives is > unclear now, but that just seems to be all the more reason to keep our > options open. > > I'm not suggesting that we fully build-in support for systemd under > Prefix and so on, but rather I'm suggesting that if leaving it open as > an option now saves us a lot of rework later we should consider it. > > (And yes, I realize that systemd is currently linux-only and why that > would make any use under Prefix difficult.) While OpenRC is likely perfectly capable of starting/stopping daemons as a normal user (with some tweaks), I expect systemd replacing init, to already have a fair bit of isssues with being just a normal unprivileged user. I may be wrong, of course. However, the notorious reputation of that piece of software aiming for system-domination doesn't really make it sound to me like it ever will be a good match for Prefix. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, Aug 6, 2012 at 6:42 AM, Fabian Groffen wrote: > On 06-08-2012 13:37:55 +0300, Samuli Suominen wrote: >> > Also, I'm not so sure if this will work correctly for Prefix. >> >> I'm sure that is easily checked and we will get feedback quickly. > > I'm sure systemd/udev will never run in (a) Prefix, so perhaps it is > more sensical not to pseudo-provide support for it. > I wouldn't be so quick to make that assumption. Right now openrc doesn't work on Prefix but there is a SoC project to change that. Why wouldn't we assume that somebody will do the same for systemd? Obviously the long-term future of systemd/openrc/alternatives is unclear now, but that just seems to be all the more reason to keep our options open. I'm not suggesting that we fully build-in support for systemd under Prefix and so on, but rather I'm suggesting that if leaving it open as an option now saves us a lot of rework later we should consider it. (And yes, I realize that systemd is currently linux-only and why that would make any use under Prefix difficult.) Rich
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On Mon, Aug 6, 2012 at 6:20 AM, Michał Górny wrote: > Most importantly, this allows us to easily find out which packages > install such files and perform global operations on them. For example, > if a particular user had systemd locations in INSTALL_MASK and changed > his mind, he can easily update his system by rebuilding all packages > inheriting systemd.eclass. > > If all packages installing udev rules start inheriting it, the above > will no longer be correct. Also, the opposite way -- rebuilding > packages installing udev rules -- won't be that easy. This seems like a bit of overloading. Right now we really lack a good way to figure out what packages COULD install files in a given place - we can only figure out which ones have installed files in that location on our own systems. If we really want that capability then I think the solution is to design it thoughtfully. Sure, some detective work with eclass inheritance might give us clues, but I wouldn't let it be a big driver behind how we use and design eclasses. That said, there might be other valid reasons for keeping udev and systemd separate eclass-wise... Rich
Re: [gentoo-dev] force verbose build log as per PMS policy?
On Mon, 6 Aug 2012 13:08:10 +0200 Michał Górny wrote: > On Mon, 06 Aug 2012 12:24:12 +0200 > Chí-Thanh Christopher Nguyễn wrote: > > > hasufell schrieb: > > > When I sum that up again... > > > - we are on gentoo and need as much information as possible for > > > backtracing, resolving bugs, checking whether CFLAGS and such have > > > been respected > > > - no need to tell the user to recompile with > > > EXTRA_ECONF="--disable-silent-rules" or similar just to be able to > > > help him > > > - some QA checks might depend on verbose build log and are not yet > > > implemented therefor > > > - if people want nice build _output_ (not log), they can use > > > --quiet-build > > > > Sorry that I am late to the party, but I would add some concerns to > > this discussion. > > > > Verbose build logs are can be several times as large as non-verbose > > ones, which can run into our Bugzilla's attachment size limit. When > > a user is unable to attach the build.log file, typically one of the > > following happens: > > About that -- maybe we should finally consider increasing it? > Nowadays, HTTP is able to handle transparent compression, so plain > text logs are pretty fine there. https://bugs.gentoo.org/show_bug.cgi?id=430160 -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On 06-08-2012 14:02:41 +0300, Samuli Suominen wrote: > rules files are often small and often get always installed, yet the > package might be running just fine without udev, the installed rules > files just don't get used > > therefore adding sys-fs/udev dependency to the eclass is out of question > and should be left for ebuilds > > therefore pseudo-prefix support should be left in place too... right? I guess so, or you'll trigger "out of prefix" errors indeed. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On 08/06/2012 01:20 PM, Michał Górny wrote: Ok, a few comments from me. [ ... ] > btw, usb_modeswitch doesn't work if left to /lib/udev with >=sys-fs/udev-187-r1: http://forums.gentoo.org/viewtopic-t-932338-highlight-.html now you know why this came up and why I committed the -r2 in tree already (and couldn't wait for this eclass review) - Samuli
Re: [gentoo-dev] force verbose build log as per PMS policy?
On Mon, 06 Aug 2012 12:24:12 +0200 Chí-Thanh Christopher Nguyễn wrote: > hasufell schrieb: > > When I sum that up again... > > - we are on gentoo and need as much information as possible for > > backtracing, resolving bugs, checking whether CFLAGS and such have > > been respected > > - no need to tell the user to recompile with > > EXTRA_ECONF="--disable-silent-rules" or similar just to be able to > > help him > > - some QA checks might depend on verbose build log and are not yet > > implemented therefor > > - if people want nice build _output_ (not log), they can use > > --quiet-build > > Sorry that I am late to the party, but I would add some concerns to > this discussion. > > Verbose build logs are can be several times as large as non-verbose > ones, which can run into our Bugzilla's attachment size limit. When a > user is unable to attach the build.log file, typically one of the > following happens: About that -- maybe we should finally consider increasing it? Nowadays, HTTP is able to handle transparent compression, so plain text logs are pretty fine there. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On 08/06/2012 01:42 PM, Fabian Groffen wrote:
On 06-08-2012 13:37:55 +0300, Samuli Suominen wrote:
Also, I'm not so sure if this will work correctly for Prefix.
I'm sure that is easily checked and we will get feedback quickly.
I'm sure systemd/udev will never run in (a) Prefix, so perhaps it is
more sensical not to pseudo-provide support for it.
after thinking about this over:
rules files are often small and often get always installed, yet the
package might be running just fine without udev, the installed rules
files just don't get used
therefore adding sys-fs/udev dependency to the eclass is out of question
and should be left for ebuilds
therefore pseudo-prefix support should be left in place too... right?
attaching latest based on mgorny's feedback...
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: udev.eclass
# @MAINTAINER:
# udev-b...@gentoo.org
# @BLURB: helper function to determine udevdir
# @DESCRIPTION:
# This eclass provides a function to get the default udev path.
# @EXAMPLE:
#
# @CODE
# inherit udev
#
# src_configure() {
# econf --with-udevdir="$(udev_get_udevdir)"
# }
# @CODE
inherit toolchain-funcs
case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
esac
RDEPEND=""
DEPEND="virtual/pkgconfig"
# @FUNCTION: _udev_get_udevdir
# @INTERNAL
# @DESCRIPTION:
# Get unprefixed udevdir.
_udev_get_udevdir() {
if $($(tc-getPKG_CONFIG) --exists udev); then
echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
else
echo -n /lib/udev
fi
}
# @FUNCTION: udev_get_udevdir
# @DESCRIPTION:
# Output the path for the udev directory (not including ${D}).
# This function always succeeds, even if udev is not installed.
# The fallback value is set to /lib/udev while waiting for
# >=sys-fs/udev-187-r1 to stabilize.
udev_get_udevdir() {
has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
debug-print-function ${FUNCNAME} "${@}"
echo -n "${EPREFIX}$(_udev_get_udevdir)"
}
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On 06-08-2012 13:37:55 +0300, Samuli Suominen wrote: > > Also, I'm not so sure if this will work correctly for Prefix. > > I'm sure that is easily checked and we will get feedback quickly. I'm sure systemd/udev will never run in (a) Prefix, so perhaps it is more sensical not to pseudo-provide support for it. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
On 08/06/2012 01:20 PM, Michał Górny wrote:
Ok, a few comments from me.
On Mon, 06 Aug 2012 13:00:08 +0300
Samuli Suominen wrote:
--- systemd.eclass 2012-08-06 12:49:20.532528219 +0300
+++ /tmp/systemd.eclass 2012-08-06 12:57:28.333542735 +0300
First of all, I'm not really convinced systemd.eclass is a good place
for this.
The main reason for introducing a separate systemd.eclass was to have
a single place to control installing systemd unit files. The rule is
quite simple here: you install systemd unit files, you inherit
the eclass.
Most importantly, this allows us to easily find out which packages
install such files and perform global operations on them. For example,
if a particular user had systemd locations in INSTALL_MASK and changed
his mind, he can easily update his system by rebuilding all packages
inheriting systemd.eclass.
If all packages installing udev rules start inheriting it, the above
will no longer be correct. Also, the opposite way -- rebuilding
packages installing udev rules -- won't be that easy.
That's not my call but I believe that putting those functions in
separate udev.eclass could be the best course of action, for the reason
stated above -- we can easily find out what installs them, and rebuild
it all at once.
OK, we can make it udev.eclass and then we can add the virtual/pkgconfig
and sys-fs/udev dependency of it.
@@ -25,6 +25,8 @@
# }
# @CODE
+inherit toolchain-funcs
+
case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
established." @@ -34,6 +36,31 @@
DEPEND="!
Secondly, I believe you shouldn't do such a thing *without* depending
on udev. Even though there is fallback here, there is another problem:
you are introducing a *potential inconsistency* between built packages,
depending on contents of udev.pc. Thus, I believe the package should
depend on the package providing it so that the dependency tree is
complete.
OK, I can agree with udev.eclass as I stated before already.
Also, I'm not so sure if this will work correctly for Prefix.
I'm sure that is easily checked and we will get feedback quickly.
+ else
+ echo -n /lib/udev
+ fi
+}
And finally, I believe we shouldn't even be making the install location
variable.
It's the upstream way to determine the path and is used treewide by
upstream configure scripts etc. for various packages already.
> Right now, the Gentoo location for udev rules is /lib/udev,
and I believe William will agree with me on this. We hadn't decided on
moving them, and thus all udev and systemd versions in the tree *will*
support /lib/udev (I still need to commit patched systemd).
If we decide to move rules to /usr/lib/udev, I believe we will move
them all at once. And then all users will have to use a newer
(or patched) udev supporting the new location (or both). In order to
enforce that, the eclass would have to block old udev versions (like
the systemd.eclass blocks old systemd versions).
The udevdir is whatever udev.pc determines it to be, and currently in
~arch it's set to /usr/lib/udev
Therefore the Gentoo udevdir is also /usr/lib/udev for ~arch
As in, packages in tree are using it already, independent of getting
this helper function to tree or not.
Making the install location dynamic is just asking for trouble.
Consider the following: user installs new udev, rebuilds package, then
downgrades udev. Package rules no longer work. That's what we would
like to avoid.
Downgrading is never a good idea when you don't know what you are doing.
+
+# @FUNCTION: systemd_get_udevdir
+# @DESCRIPTION:
+# Output the path for the udev directory (not including ${D}).
+# This function always succeeds, even if udev is not installed.
+# Dependencies need to include sys-fs/udev or otherwise
+# the fallback return value is /lib/udev.
+systemd_get_udevdir() {
+ has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
+ debug-print-function ${FUNCNAME} "${@}"
+
+ echo -n "${EPREFIX}$(_systemd_get_udevdir)"
+}
+
# @FUNCTION: _systemd_get_unitdir
# @INTERNAL
# @DESCRIPTION:
As a final note, please note that this is mostly my opinion as systemd
maintainer. I believe William has a final word on udev itself.
Summarizing:
- Will call this udev.eclass and add the dependencies for udev and
pkg-config
- Gentoo's udevdir is already set to /usr/lib/udev by
>=sys-fs/udev-187-r1 in Portage, and is widely queried by upstream
configure scripts
We should leave it like it is now, and get this helper function ASAP in
tree to get things consistent again
- Samuli
Re: [gentoo-dev] force verbose build log as per PMS policy?
hasufell schrieb: > When I sum that up again... > - we are on gentoo and need as much information as possible for > backtracing, resolving bugs, checking whether CFLAGS and such have been > respected > - no need to tell the user to recompile with > EXTRA_ECONF="--disable-silent-rules" or similar just to be able to help him > - some QA checks might depend on verbose build log and are not yet > implemented therefor > - if people want nice build _output_ (not log), they can use --quiet-build Sorry that I am late to the party, but I would add some concerns to this discussion. Verbose build logs are can be several times as large as non-verbose ones, which can run into our Bugzilla's attachment size limit. When a user is unable to attach the build.log file, typically one of the following happens: 1. User compresses build.log with a common compressor like gzip, bzip2 or xz and manually sets the attachment MIME type correctly (best case). 2. User makes a compressed tarball, containing a single file 3. User cuts off the build.log somewhere in the middle, supplies the bottom part 4. User uploads build.log to a public file hoster or his own private web server, the link expires / 404s after some time (IMO worst case). In my opinion, build verbosity should not be dictated by policy, but rather left to the discretion of the maintainer. After all, he is the one who needs to deal with the bug reports. Having verbose build logs by default (with the possibility for the maintainer to override) would be ok with me though. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
Ok, a few comments from me.
On Mon, 06 Aug 2012 13:00:08 +0300
Samuli Suominen wrote:
> --- systemd.eclass2012-08-06 12:49:20.532528219 +0300
> +++ /tmp/systemd.eclass 2012-08-06 12:57:28.333542735 +0300
First of all, I'm not really convinced systemd.eclass is a good place
for this.
The main reason for introducing a separate systemd.eclass was to have
a single place to control installing systemd unit files. The rule is
quite simple here: you install systemd unit files, you inherit
the eclass.
Most importantly, this allows us to easily find out which packages
install such files and perform global operations on them. For example,
if a particular user had systemd locations in INSTALL_MASK and changed
his mind, he can easily update his system by rebuilding all packages
inheriting systemd.eclass.
If all packages installing udev rules start inheriting it, the above
will no longer be correct. Also, the opposite way -- rebuilding
packages installing udev rules -- won't be that easy.
That's not my call but I believe that putting those functions in
separate udev.eclass could be the best course of action, for the reason
stated above -- we can easily find out what installs them, and rebuild
it all at once.
> @@ -25,6 +25,8 @@
> # }
> # @CODE
>
> +inherit toolchain-funcs
> +
> case ${EAPI:-0} in
> 0|1|2|3|4) ;;
> *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet
> established." @@ -34,6 +36,31 @@
> DEPEND="! !=sys-apps/systemd-37-r1"
>
> +# @FUNCTION: _systemd_get_udevdir
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Get unprefixed udevdir.
> +_systemd_get_udevdir() {
> + if $($(tc-getPKG_CONFIG) --exists udev); then
> + echo -n "$($(tc-getPKG_CONFIG) --variable=udevdir
> udev)"
Secondly, I believe you shouldn't do such a thing *without* depending
on udev. Even though there is fallback here, there is another problem:
you are introducing a *potential inconsistency* between built packages,
depending on contents of udev.pc. Thus, I believe the package should
depend on the package providing it so that the dependency tree is
complete.
Also, I'm not so sure if this will work correctly for Prefix.
> + else
> + echo -n /lib/udev
> + fi
> +}
And finally, I believe we shouldn't even be making the install location
variable. Right now, the Gentoo location for udev rules is /lib/udev,
and I believe William will agree with me on this. We hadn't decided on
moving them, and thus all udev and systemd versions in the tree *will*
support /lib/udev (I still need to commit patched systemd).
If we decide to move rules to /usr/lib/udev, I believe we will move
them all at once. And then all users will have to use a newer
(or patched) udev supporting the new location (or both). In order to
enforce that, the eclass would have to block old udev versions (like
the systemd.eclass blocks old systemd versions).
Making the install location dynamic is just asking for trouble.
Consider the following: user installs new udev, rebuilds package, then
downgrades udev. Package rules no longer work. That's what we would
like to avoid.
> +
> +# @FUNCTION: systemd_get_udevdir
> +# @DESCRIPTION:
> +# Output the path for the udev directory (not including ${D}).
> +# This function always succeeds, even if udev is not installed.
> +# Dependencies need to include sys-fs/udev or otherwise
> +# the fallback return value is /lib/udev.
> +systemd_get_udevdir() {
> + has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX=
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + echo -n "${EPREFIX}$(_systemd_get_udevdir)"
> +}
> +
> # @FUNCTION: _systemd_get_unitdir
> # @INTERNAL
> # @DESCRIPTION:
As a final note, please note that this is mostly my opinion as systemd
maintainer. I believe William has a final word on udev itself.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
[gentoo-dev] [RFC] systemd.eclass: Patch for new function systemd_get_udevdir()
Patch to avoid duplicating this code to every ebuild.
The second attachment is an example use case for the function.
Soon as this is in, I'll start mass converting the tree for this...
- Samuli
--- systemd.eclass 2012-08-06 12:49:20.532528219 +0300
+++ /tmp/systemd.eclass 2012-08-06 12:57:28.333542735 +0300
@@ -25,6 +25,8 @@
# }
# @CODE
+inherit toolchain-funcs
+
case ${EAPI:-0} in
0|1|2|3|4) ;;
*) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
@@ -34,6 +36,31 @@
DEPEND="!--- usb_modeswitch-1.2.3_p20120531-r2.ebuild 2012-08-06 12:59:07.308545675 +0300
+++ /tmp/usb_modeswitch-1.2.3_p20120531-r2.ebuild 2012-08-06 12:46:17.556522775 +0300
@@ -3,7 +3,7 @@
# $Header: /var/cvsroot/gentoo-x86/sys-apps/usb_modeswitch/usb_modeswitch-1.2.3_p20120531-r2.ebuild,v 1.2 2012/08/06 08:22:44 ssuominen Exp $
EAPI=4
-inherit linux-info toolchain-funcs
+inherit linux-info toolchain-funcs systemd
MY_PN=${PN/_/-}
MY_P=${MY_PN}-${PV/_p*}
@@ -42,7 +42,7 @@
src_install() {
emake \
DESTDIR="${D}" \
- UDEVDIR="${D}/$($(tc-getPKG_CONFIG) --variable=udevdir udev)" \
+ UDEVDIR="${D}/$(systemd_get_udevdir)" \
install
dodoc ChangeLog README
@@ -50,7 +50,7 @@
pushd ../${MY_PN}-data-${DATA_VER} >/dev/null
emake \
DESTDIR="${D}" \
- RULESDIR="${D}/$($(tc-getPKG_CONFIG) --variable=udevdir udev)/rules.d" \
+ RULESDIR="${D}/$(systemd_get_udevdir)/rules.d" \
files-install db-install
docinto data
dodoc ChangeLog README
