Re: [gentoo-dev] rfc: use of the /run directory
On Tue, 17 May 2011 19:12:38 -0500 William Hubbs willi...@gentoo.org wrote: On Tue, May 17, 2011 at 11:50:32PM +0100, Ciaran McCreesh wrote: I would be interested to hear how you plan to do the migration, given that everyone else has managed to screw it up... I'm not sure what you mean here. Openrc git will mount a tmpfs on /run if it exists and create a lock directory inside the tmpfs. To make it work, I just need a new release of baselayout to make the /run directory. Then, I also need to figure out where in the boot process to make the symbolic links from /var/lock to /run/lock and from /var/run to /run. what else am I missing? The problem is that packages that have things installed to the old directories are going to get confused when upgraded if things have been moved around behind their backs. You may be better having both directories present, and not attempting to rename or move things at all. Then start fixing packages that install to the old directories. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Removal of kdeprefix news item
On Sun, 22 May 2011 16:52:55 -0400 Jonathan Callen a...@gentoo.org wrote: Here's the updated news item, which I will be committing very shortly. Please note that there is absolutely no version of portage that was not in package.mask that would have problems with an EAPI-2 atom in a news item because EAPI-2 support was added to portage at the same time as news item support (they both appeared in portage 2.1.6). Please don't. This needs to be figured out properly. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
On Mon, 23 May 2011 12:35:12 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
You may be better having both directories present, and not
attempting to rename or move things at all. Then start fixing
packages that install to the old directories.
As I understand it, that's precisely what William's plan is.
$ ls -ld /var/{lock/run}
/var/lock - /run/lock
/var/run - /run/
No, not as symlinks. Having both directories present as proper,
unrelated directories, and explicitly migrating apps that install things
to the old directory.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
On Mon, 23 May 2011 12:35:12 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
As I understand it, that's precisely what William's plan is.
$ ls -ld /var/{lock/run}
/var/lock - /run/lock
/var/run - /run/
This should work transparently for all existing applications.
The only way this would fail is if they do an incorrect stat() on
/var/run and error out if it's a symbolic link. OTOH, it's precisely
to iron out such kinks that we have ~arch.
What if a daemon tries to do braindead compat attempt through creating
a pidfile in both directories?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
On Mon, May 23, 2011 at 12:43 PM, Michał Górny mgo...@gentoo.org wrote:
On Mon, 23 May 2011 12:35:12 +0530
Nirbheek Chauhan nirbh...@gentoo.org wrote:
As I understand it, that's precisely what William's plan is.
$ ls -ld /var/{lock/run}
/var/lock - /run/lock
/var/run - /run/
This should work transparently for all existing applications.
The only way this would fail is if they do an incorrect stat() on
/var/run and error out if it's a symbolic link. OTOH, it's precisely
to iron out such kinks that we have ~arch.
What if a daemon tries to do braindead compat attempt through creating
a pidfile in both directories?
I think the answer is obvious — we patch it to use /run/lock ...
--
~Nirbheek Chauhan
Gentoo GNOME+Mozilla Team
[gentoo-dev] Should server be a global use flag?
Hi all,
I was looking at use.desc/use.local.desc to see if the server flag is
global or not. I was surprised to see that it is not. There are 26
packages that use a local server flag and they all say something to
the effect Enable ${PN} server support.
Should we not promote this to global with a description
server - Enable the packages server component
If yes, what's the procedure? We'd have to have a lot of metadata.xml's
change. I'm not sure what happens if you simultaneously have a local
and global USE flag by the same name (although I'm going to test in a
minute on an overlay :)
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
Re: [gentoo-dev] Should server be a global use flag?
On Mon, 23 May 2011 10:26:49 -0400 Anthony G. Basile bluen...@gentoo.org wrote: If yes, what's the procedure? Add the global one to use.desc. Then remove the local ones from their respective metadata.xml files. use.local.desc will be adjusted accordingly in time - no need to hurry. We'd have to have a lot of metadata.xml's change. I'm not sure what happens if you simultaneously have a local and global USE flag by the same name (although I'm going to test in a minute on an overlay :) They can happily coexist. No need to remove them simultaneously. Regards, jer
Re: [gentoo-dev] Should server be a global use flag?
On Mon, 23 May 2011, Anthony G Basile wrote:
I was looking at use.desc/use.local.desc to see if the server flag is
global or not. I was surprised to see that it is not. There are 26
packages that use a local server flag and they all say something to
the effect Enable ${PN} server support.
From http://devmanual.gentoo.org/general-concepts/use-flags/:
| If the effect of the USE flag upon pkg-one is substantially
| different from the effect it has upon pkg-two, then the flag is not
| a suitable candidate for being made a global flag. In particular,
| note that if client and server USE flags are ever introduced, they
| can not be global USE flags for this reason.
Ulrich
Re: [gentoo-dev] Should server be a global use flag?
On 05/23/2011 10:48 AM, Ulrich Mueller wrote:
On Mon, 23 May 2011, Anthony G Basile wrote:
I was looking at use.desc/use.local.desc to see if the server flag is
global or not. I was surprised to see that it is not. There are 26
packages that use a local server flag and they all say something to
the effect Enable ${PN} server support.
From http://devmanual.gentoo.org/general-concepts/use-flags/:
| If the effect of the USE flag upon pkg-one is substantially
| different from the effect it has upon pkg-two, then the flag is not
| a suitable candidate for being made a global flag. In particular,
| note that if client and server USE flags are ever introduced, they
| can not be global USE flags for this reason.
Ulrich
My point was that the server flag has the *same* effect on all these
packages, ie to turn on their server support. But the point was made on
#gentoo-dev that what is a server for one package is not the same as a
server for another package. Thinking along those lines, the server
flag has a *different* effect on each package.
Reflecting on this, the stricter definition makes more sense, so I
retract my point.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
Re: [gentoo-dev] Should server be a global use flag?
On Mon, 23 May 2011 10:26:49 -0400
Anthony G. Basile bluen...@gentoo.org wrote:
Hi all,
I was looking at use.desc/use.local.desc to see if the server flag
is global or not. I was surprised to see that it is not. There are
26 packages that use a local server flag and they all say something
to the effect Enable ${PN} server support.
Should we not promote this to global with a description
server - Enable the packages server component
app-admin/bcfg2:server - Installs scripts to be used on the server-side
of this app
- If it means, to install a server and scripts, then YES. It should be
clarified what this flag actually does install as extra.
app-mobilephone/obexd:server - Enables server installation, it's
incompatible with obex-data-server
provided one
- Is it really really necessary to describe that incompatibility? If
no, YES.
app-office/akonadi-server:server - Use locally installed database
server.
- Again, what does it mean? Does it install the database server too? If
yes, YES, but again the description would need to be changed or
omitted.
dev-libs/tntnet:server - Enable tntnet server daemon
- YES.
dev-python/dap:server - Enable OpenDAP server support
- YES if it actually installs a server/daemon.
dev-ruby/rubygems:server - Install support for the rubygems server
- YES if it actually installs a server/daemon.
dev-vcs/cvs:server - Enable server support
- YES if it actually installs a server/daemon.
games-strategy/wesnoth:server - Enable compilation of server
- YES: if it compiles it, then it installs a server/daemon.
media-plugins/vdr-streamdev:server - Compile the VDR plugin
vdr-streamdev-server that allows
remote systems to access the DVB
cards used for the local VDR
- YES if it actually installs a server/daemon, but the description is
rather more informative than enable server component would be.
media-sound/xmms2:server - Build xmms2 player daemon (otherwise only
clients are built)
- YES: it actually installs a server/daemon. That clients will be built
regardless of this USE flag is irrelevant.
net-analyzer/zabbix:server - Enable zabbix server
- YES if it actually installs a server/daemon.
net-fs/coda:server - Build and install the server components of coda
filesystem. Note: at least one of client/server flags must be enabled.
- YES if it actually installs a server/daemon. REQUIRED_USE should
replace the need to force either server or client in USE flags.
net-fs/samba:server - Enables the server part
- YES.
net-irc/quassel:server - Build the server binary. If this USE flag is
disabled, the 'core' server binary for quassel is not built, and cannot
be used. You need this enabled on the server, but you might want to
disable it on the client.
- YES. Lots of irrelevant information after the first sentence. If you
want to explain how to use the ebuild or installed package, then
write some real documentation and put it on the website.
net-libs/libinfinity:server - Build and install the server binary
including init.d/conf.d-scripts. Needed if you want to host an infinote
server for gobby.
- YES. Again write some documentation instead of abusing a USE flag
description to explain how the package works.
net-libs/libssh:server - Build with SSH server support
- YES if it actually installs a server/daemon. It's not clear whether
this just means it compiles in server components into the library it
installs.
net-libs/wt:server - Compile in stand-alone httpd connector
- Looks like a YES.
net-misc/dhcp:server - Install the dhcpd and dhcrelay programs
- YES.
net-misc/knock:server - Installs the knockd server daemon.
- YES.
net-misc/tigervnc:server - Build TigerVNC server
- YES.
net-misc/tightvnc:server - Build vncserver. Allows us to only build
server on one machine if set, build only viewer otherwise.
- YES. Again, write the HOWTO instead of abusing a USE flag description.
sci-biology/ucsc-genome-browser:server - Install genome browser Web
application. If this flag is
off, only libraries and
utilities from the suite are
installed.
- It isn't clear, but would probably boil down to a YES. The second
sentence is irrelevant in the context.
sci-mathematics/yacas:server - Build the network server version
- Build the version? You mean build the daemon? If so, YES.
sys-cluster/pvfs2:server - Enable compilation of server code
- Server code? If it builds and installs a daemon, then YES.
sys-cluster/torque:server - Enable compilation of pbs_server and
pbs_sched.
- YES.
sys-fs/owfs:server - Enable building the OWFS server (owserver)
- YES.
(I
Re: [gentoo-dev] Should server be a global use flag?
El lun, 23-05-2011 a las 17:19 +0200, Jeroen Roovers escribió: [...] app-mobilephone/obexd:server - Enables server installation, it's incompatible with obex-data-server provided one - Is it really really necessary to describe that incompatibility? If no, YES. I want that description as-is to prevent some people thinking obexd[server] should be used instead of obex-data-server even if all stuff still needs obex-data-server and that one is incompatible with obexd one. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Removal of kdeprefix news item
Ulrich Mueller u...@gentoo.org said: On Thu, 19 May 2011, Alec Warner wrote: You should file a bug about that; I'm sure one of the portage guys can change the crap code I wrote 4 years ago to use the normal dependency checking code for installed atoms. But we wouldn't know if users have the updated portage version installed, so it doesn't help for the current news item. I think for a proper solution we would have to increase the number of the News-Item-Format. Maybe even add a new header field for the EAPI. This seems like the absolute easiest solution to use going forward. Having an 'eapi' file present seems workable as well, though I'm not certain which is the easiest for Portage to implement today. Are there any other suggestions, or does anyone disagree with Ulrich's suggestion? -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com signature.asc Description: Digital signature
Re: [gentoo-dev] Should server be a global use flag?
Jeroen Roovers wrote: (I find myself wondering why so much information is being jammed into USE flag descriptions that /should/ be available in HOWTOs from upstream, or else should be written down in HOWTOs we maintain ourselves - we (Gentoo) used to be good at providing HOWTOs as needed and it's a good tradition to keep up. It helps the entire open source community and not just our users, too.) Anyway, count the YESs above. Maybe some people want to comment/explain/defend how they wrote their descriptions, so don't touch them just yet. :) jer The reason the info is there is so that users, like me, know what the USE flag is for. Me personally, I still think some of them don't help much and need more info but it is better than it used to be. So, if you can make them shorter and users still able to figure out what they do, great. If not, then the info needs to stay. Us users need it. Thanks. Dale :-) :-)
Re: [gentoo-dev] Should server be a global use flag?
On Mon, May 23, 2011 at 12:27 PM, Dale rdalek1...@gmail.com wrote: The reason the info is there is so that users, like me, know what the USE flag is for. Me personally, I still think some of them don't help much and need more info but it is better than it used to be. So, if you can make them shorter and users still able to figure out what they do, great. If not, then the info needs to stay. Us users need it. ++ A description of USE=foo enables foo support is just about useless. Why even have the description at all in that case? What I want to know is whether I want foo support. A description of Disables 99% of the functionality in chromium but still lets you parse the config files from a command line on an embedded system lets me know that unless I'm doing something exotic it isn't for me. A long sentence is probably the right level of detail. Two sentences is probably warranted if messing with the flag can cause havoc. Rich
Re: [gentoo-dev] Should server be a global use flag?
On Mon, 23 May 2011 16:48:15 +0200
Ulrich Mueller u...@gentoo.org wrote:
On Mon, 23 May 2011, Anthony G Basile wrote:
I was looking at use.desc/use.local.desc to see if the server
flag is global or not. I was surprised to see that it is not.
There are 26 packages that use a local server flag and they all
say something to the effect Enable ${PN} server support.
From http://devmanual.gentoo.org/general-concepts/use-flags/:
| If the effect of the USE flag upon pkg-one is substantially
| different from the effect it has upon pkg-two, then the flag is not
| a suitable candidate for being made a global flag. In particular,
| note that if client and server USE flags are ever introduced, they
| can not be global USE flags for this reason.
With that definition, USE=crypt should definitely not be global.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] Should server be a global use flag?
On 05/23/2011 12:37 PM, Michał Górny wrote:
On Mon, 23 May 2011 16:48:15 +0200
Ulrich Mueller u...@gentoo.org wrote:
On Mon, 23 May 2011, Anthony G Basile wrote:
I was looking at use.desc/use.local.desc to see if the server
flag is global or not. I was surprised to see that it is not.
There are 26 packages that use a local server flag and they all
say something to the effect Enable ${PN} server support.
From http://devmanual.gentoo.org/general-concepts/use-flags/:
| If the effect of the USE flag upon pkg-one is substantially
| different from the effect it has upon pkg-two, then the flag is not
| a suitable candidate for being made a global flag. In particular,
| note that if client and server USE flags are ever introduced, they
| can not be global USE flags for this reason.
With that definition, USE=crypt should definitely not be global.
Yep. Eg. USE=crypt for evolution means dependence on app-crypt/gnupg
and is local while USE=crypt for thunderbird means dependency on
x11-plugins/enigmail and is global. Both are substantially different
from what USE=crypt means for util-linux which enables crypto-loop and
is a global.
Ouch!
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail: bluen...@gentoo.org
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535
GnuPG ID : D0455535
Re: [gentoo-dev] Should server be a global use flag?
On Mon, 23 May 2011 11:27:18 -0500 Dale rdalek1...@gmail.com wrote: Jeroen Roovers wrote: (I find myself wondering why so much information is being jammed into USE flag descriptions that /should/ be available in HOWTOs from upstream, or else should be written down in HOWTOs we maintain ourselves - we (Gentoo) used to be good at providing HOWTOs as needed and it's a good tradition to keep up. It helps the entire open source community and not just our users, too.) Anyway, count the YESs above. Maybe some people want to comment/explain/defend how they wrote their descriptions, so don't touch them just yet. :) The reason the info is there is so that users, like me, know what the USE flag is for. Me personally, I still think some of them don't help much and need more info but it is better than it used to be. So, if you can make them shorter and users still able to figure out what they do, great. If not, then the info needs to stay. Us users need it. What the hell are you talking about? *I* am a user... Please make a direct point in reply to my superficial criticism on each USE=server flag or reply to what you quoted above. I don't see anything constructive or relevant in your reply. You seem to argue that I can somehow technically or magically derive a USE flag's meaning whereas you cannot. If you want to defend that, then start a new thread. jer
Re: [gentoo-dev] Should server be a global use flag?
Jeroen Roovers wrote: On Mon, 23 May 2011 11:27:18 -0500 Dalerdalek1...@gmail.com wrote: Jeroen Roovers wrote: (I find myself wondering why so much information is being jammed into USE flag descriptions that /should/ be available in HOWTOs from upstream, or else should be written down in HOWTOs we maintain ourselves - we (Gentoo) used to be good at providing HOWTOs as needed and it's a good tradition to keep up. It helps the entire open source community and not just our users, too.) Anyway, count the YESs above. Maybe some people want to comment/explain/defend how they wrote their descriptions, so don't touch them just yet. :) The reason the info is there is so that users, like me, know what the USE flag is for. Me personally, I still think some of them don't help much and need more info but it is better than it used to be. So, if you can make them shorter and users still able to figure out what they do, great. If not, then the info needs to stay. Us users need it. What the hell are you talking about? *I* am a user... Please make a direct point in reply to my superficial criticism on each USE=server flag or reply to what you quoted above. I don't see anything constructive or relevant in your reply. You seem to argue that I can somehow technically or magically derive a USE flag's meaning whereas you cannot. If you want to defend that, then start a new thread. jer I was talking about what you wrote and I quoted above in my reply. Since you want to have the attitude you have, please disregard my reply and I guess another reply to mine which agreed with me and even elaborated on the point I made. I guess the two if us misread what you wrote. Sorry to have wrinkled your feathers. Dale :-) :-)
