[gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
Steven J. Long posted on Sat, 01 Mar 2014 06:48:54 + as excerpted: I for one prefer a distro to do a bit of work and make my life easier, since it makes life easier for everyone who uses the distro. Why the hell should I care if some bindist can't etc-update? WTF does that have to do with Gentoo? Because if they can't etc-update, they'll come up with some other solution that might not work so well for gentoo, and as upstream for some number of packages they'll propagate that solution, causing more trouble for gentoo trying to fix the impedance mismatch between their way and ours. Which is basically where we're at. Upstream came up with this /etc/ config modifying a package-specific default config somewhere else random on the system idea because they didn't have a good etc-update, and now we have to figure out the most sane way to try to integrate that with gentoo's etc-update based system. If we'd have been able to propagate etc-update or similar before they came up with their solution, we'd not have this problem, but of course that's a historical if that we can't go back and revisit... except in possibly trying to get something like etc- update propagated now to reduce similar problems in the future. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Possibility of overriding user defined INSTALL_MASK from an ebuild?
Dnia 2014-03-01, o godz. 07:28:35 Samuli Suominen ssuomi...@gentoo.org napisał(a): On 01/03/14 04:55, Joshua Kinard wrote: 3. Some profiles also override INSTALL_MASK, such as Gentoo/FreeBSD, because systemd does not apply there. Wow. I don't think we should allow this without first having exactly what was suggested in this thread, a way of redefining the order away from INSTALL_MASK_ORDER=profile:ebuild:user, because if we allow INSTALL_MASK usage in profiles without having a setting for the order, it'll always be INSTALL_MASK_ORDER=profile:user, and it's very hard for user to get his setting respected even if he wanted to. INSTALL_MASK is not stacked. That is, if user sets INSTALL_MASK, profile setting gets erased. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Boost 1.54 and 1.55 unmasking
Hi. In a few days, i would like to proceed with unmasking of dev-libs/boost-1.54.0-r1 and dev-libs/boost-1.55.0-r1. There are quite a few breakages regarding them(not much more than 1.53 ones), see [1] for details. Most of the unstable revdeps are up-to-date with recent changes. Also 1.55 contains valueable enhancements, like [2], so it would be nice if it will be tested widely. [1] - https://bugs.gentoo.org/show_bug.cgi?id=boost-1.54 [2] - https://bugs.gentoo.org/show_bug.cgi?id=462374 -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
[gentoo-dev] help
-- andrei vinogradov
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sat, Mar 01, 2014 at 06:48:54AM +, Steven J. Long wrote: On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote: On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote: But let's be real here: if I install something and want to configure its system-wide bits, the first place I go is ALWAYS /etc. When I don't find it there, with the rest of the system config files, my day gets a little worse and I lose a bit of time trying to interrogate a search engine for the answer. And that's annoying. That sucks. This hasn't changed. The configuration files these packages are putting in /lib are not meant to be edited; they are the package provided defaults. If you want to override one of them, you do that in a file with the same path and name in /etc, like I mentioned in another message in this thread. The problem, as has been explained many many times, is that the rest of the config is somewhere random on the system. But you knew that, right? You were just telling a half-truth, effectively. No sir, I was not telling a half-truth. If the default configuration is stored in /lib/udev/rules.d for example, and you can override that default by dropping files of the same name in /etc/udev/rules.d, I don't see what the concern is. I for one prefer a distro to do a bit of work and make my life easier, since it makes life easier for everyone who uses the distro. Why the hell should I care if some bindist can't etc-update? WTF does that have to do with Gentoo? With this method, you don't need to etc-update, so I would say that in a way this is easier. Your system-admin-provided files in /etc are not owned by the packages, just the files in /lib are. If I wanted a shitty distro that didn't bother to do anything at all, I'd use LFS. At least they don't pretend, then fall over themselves to do a crap load of work rather than admit a mistake; that hey, y'know what? Some of those things from 30 years ago were a damn good idea, and maybe just maybe, they worked some of these issues out back then, so we could stand on their shoulders instead of digging through their garbage. I'm not totally against keeping things from the past. It is just a case of evaluating those things and seeing whether they are still relevant. signature.asc Description: Digital signature
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
Le samedi 01 mars 2014 à 10:06 -0600, William Hubbs a écrit : On Sat, Mar 01, 2014 at 06:48:54AM +, Steven J. Long wrote: On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote: On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote: But let's be real here: if I install something and want to configure its system-wide bits, the first place I go is ALWAYS /etc. When I don't find it there, with the rest of the system config files, my day gets a little worse and I lose a bit of time trying to interrogate a search engine for the answer. And that's annoying. That sucks. This hasn't changed. The configuration files these packages are putting in /lib are not meant to be edited; they are the package provided defaults. If you want to override one of them, you do that in a file with the same path and name in /etc, like I mentioned in another message in this thread. The problem, as has been explained many many times, is that the rest of the config is somewhere random on the system. But you knew that, right? You were just telling a half-truth, effectively. No sir, I was not telling a half-truth. If the default configuration is stored in /lib/udev/rules.d for example, and you can override that default by dropping files of the same name in /etc/udev/rules.d, I don't see what the concern is. I for one prefer a distro to do a bit of work and make my life easier, since it makes life easier for everyone who uses the distro. Why the hell should I care if some bindist can't etc-update? WTF does that have to do with Gentoo? With this method, you don't need to etc-update, so I would say that in a way this is easier. Your system-admin-provided files in /etc are not owned by the packages, just the files in /lib are. If I wanted a shitty distro that didn't bother to do anything at all, I'd use LFS. At least they don't pretend, then fall over themselves to do a crap load of work rather than admit a mistake; that hey, y'know what? Some of those things from 30 years ago were a damn good idea, and maybe just maybe, they worked some of these issues out back then, so we could stand on their shoulders instead of digging through their garbage. I'm not totally against keeping things from the past. It is just a case of evaluating those things and seeing whether they are still relevant. I think the biggest issue here is that if the filename changes or the setting that is overridden changes, then end-user or sysadmin is the one that will suffer from settings not being applied and not knowing why. This already happened with systemd/udev and net rules for example and I am pretty sure in a couple of other packages but I have no other examples on the top of my head. Sure at some point you have to make things evolve but this upstream solution simply isn't nice for its users. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Re: FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
On Sat, Mar 1, 2014 at 8:06 AM, William Hubbs willi...@gentoo.org wrote:
On Sat, Mar 01, 2014 at 06:48:54AM +, Steven J. Long wrote:
On Fri, Feb 28, 2014 at 09:31:08PM -0600, William Hubbs wrote:
On Fri, Feb 28, 2014 at 09:47:05PM -0500, Wyatt Epp wrote:
But let's be real here: if I install something and
want to configure its system-wide bits, the first place I go is
ALWAYS
/etc. When I don't find it there, with the rest of the system config
files, my day gets a little worse and I lose a bit of time trying to
interrogate a search engine for the answer. And that's annoying.
That sucks.
This hasn't changed.
The configuration files these packages are putting in /lib are not
meant to be edited; they are the package provided defaults. If you want
to override one of them, you do that in a file with the same path and
name in /etc, like I mentioned in another message in this thread.
The problem, as has been explained many many times, is that the rest
of the config is somewhere random on the system. But you knew that,
right? You were just telling a half-truth, effectively.
No sir, I was not telling a half-truth.
If the default configuration is stored in /lib/udev/rules.d for example,
and you can override that default by dropping files of the same name in
/etc/udev/rules.d, I don't see what the concern is.
My understanding of his point was that right now configs are stored in one
file or in one directory.
/etc/default/foo perhaps or /etc/foo.d/{a,b,c}
it is easy for a some users to determine, using existing tools (vim, less,
etc.) to view what the configuration state is.
When the default configs are in /lib/udev/.../ and the over-rides are in
/etc/udev/.../ that is perhaps less clear. Many applications already
provide app specific tools for this. You can run apt-config dump to dump
your entire apt configuration (on debian / ubuntu) for example. I'm unsure
if polkit or dbus have a tool that will read in the configuration and dump
what the daemon thinks the state would be (if it loaded it.) (puppet has
I think part of the oddity of this objection is that this move is years old
already.
gconf, dconf, polkit, dbus, all do stuff like this. I actually find the
solution somewhat elegant from my side as a sysadmin.
-A
I for one prefer a distro to do a bit of work and make my life easier,
since it makes life easier for everyone who uses the distro. Why the
hell should I care if some bindist can't etc-update? WTF does that
have to do with Gentoo?
With this method, you don't need to etc-update, so I would say that in a
way this is easier. Your system-admin-provided files in /etc are not
owned by the packages, just the files in /lib are.
If I wanted a shitty distro that didn't bother to do anything at
all, I'd use LFS. At least they don't pretend, then fall over themselves
to do a crap load of work rather than admit a mistake; that hey, y'know
what? Some of those things from 30 years ago were a damn good idea,
and maybe just maybe, they worked some of these issues out back then,
so we could stand on their shoulders instead of digging through
their garbage.
I'm not totally against keeping things from the past. It is just a case
of evaluating those things and seeing whether they are still relevant.
[gentoo-dev] Last rites: app-emacs/delicious
# Ulrich Müller u...@gentoo.org (1 Mar 2014) # Version 0.3 does not work with Emacs 24; git master # also fails, because of changed Delicious API. # According to upstream, a new release is unlikely. # Masked for removal in 60 days, bug 502168. app-emacs/delicious pgpULkfXDK4iQ.pgp Description: PGP signature
Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)
Dnia 2014-02-28, o godz. 15:59:35 hasufell hasuf...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Samuli Suominen: On 28/02/14 13:15, Patrick Lauer wrote: On 02/27/2014 09:08 PM, Anthony G. Basile wrote: Hi everyone, I'm putting the call out there for any agenda items for the next Council meeting, which will be held on March 11, 2014 at 1900 UTC. This is short notice but we got off track because of FOSDEM and we're going to try to get back on track. So far, the only item is final ratification of glep 63 [1]. Since it's still a bit cold I'd like to start a nice fire to warm us up: I'd like QA and Council to figure out how much we care about FHS. My main complaint is some projects (including e.g. systemd and apparently now also udev) storing config files in /lib and/or /usr/lib. From FHS' point of view this is totally wrong, config files go to /etc Only libraries should be in /lib. Wow. What about libtool .la text files? What about kernel modules? What about the genereted modules.* data in /lib/modules/$version/ which are used in early boot by eg. kmod-static-nodes? What about the binaries of OpenRC in /lib/rc, they aren't libraries? And what about vendor modprobe.d files in /lib/modprobe.d? I could continue this all day. I'm just trying to point out Only libraries should be in /lib. is complete bs and does not work. Does FHS really articulate it the way you said it, Only libraries should be in /lib. or was that your own interpretation of it? I'm not really expecting an answer as I'm already convinced FHS is so badly outdated it's sad it doesn't suit modern systems. I hope they will catch up at some point. - Samuli In addition to the questions of Samuli... What about python, perl, ruby and whatnot script languages. What about haskell and pascal? Some of them files are reported to be data files. What about erlangs .erl and .hrl (text)? What about mono/C# .exe and .dll (are they architecture-dependant or can I treat them as data files and move them to /usr/share/?) What about non-trivial packages like fpc, firefox, portage and libreoffice that all violate FHS? Who will fix it and maintain that stuff downstream? What about /opt, we don't follow that either? What about /usr/include and .hpp files (only C is valid according to FHS)? Who will fix boost? I skip the part of running some funny find commands on my local system. Please ping me if this thread brings something constructive or decisive. I don't have time to read all the trolling and useless whining, yet I don't want to miss if somewhere in the middle of this crap QA or someone decides to apply a policy that will affect me. Thanks. -- Best regards, Michał Górny signature.asc Description: PGP signature
