Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Fri, Sep 15, 2006 at 07:39:35PM +0100, Ciaran McCreesh wrote: On Thu, 14 Sep 2006 08:51:09 +0200 Harald van Dijk [EMAIL PROTECTED] wrote: | On Mon, Sep 11, 2006 at 11:22:11PM +0100, Ciaran McCreesh wrote: | Comments both on the nature and the specifics of the specification | would be welcomed. In particular, I'd like to know if people think | we're mandating the appropriate degree of specificity and whether | we're providing sufficient generality to avoid overly restricting | innovation. | | I think this is overly restrictive, actually. It's a good idea to | specify which files and directories will be matched by CONFIG_PROTECT | and _MASK, since that's something ebuilds end up using, but it may be | better to leave the details on how they will be protected up to the | package manager (which can in turn make it configurable for the user). | For one example of what a package manager, if configured to do so, | should in my opinion be allowed to do: automatically remove unmodified | and abandoned configuration files on updates. (This is not the same as | setting CONFIG_PROTECT=-*.) For another, a package manager, if | configured to do so, should in my opinion be allowed to store the | config files on a (possibly local) cvs/svn server in addition to the | real filesystem, avoiding ._cfg* files altogether. Specifying how | they will be protected prevents things like this. Hm, the specification doesn't preclude additional functionality. It just describes how things should work when normal configuration protection is in action. Sure, the specification does not prohibit package managers from having behaviour that can be configured to not match what is specified, but that isn't the point. The point is that if configured as such, it isn't a Gentoo package manager anymore. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Mon, Sep 11, 2006 at 11:22:11PM +0100, Ciaran McCreesh wrote: Protected locations are determined by the ``CONFIG_PROTECT`` environment variable, which is defined in the profiles and which may be augmented or overridden by the current environment and user configuration files. The user env override has no relevance to ebuilds relying on it, thus doesn't have any business being mandated imo (it's implementation choice, not requirement of ebuilds). ~harring pgpd5xrCtdXQ9.pgp Description: PGP signature
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Tue, Sep 12, 2006 at 12:15:34AM +0100, Ciaran McCreesh wrote: On Mon, 11 Sep 2006 16:02:53 -0700 Chris White [EMAIL PROTECTED] wrote: | On Monday 11 September 2006 15:22, Ciaran McCreesh wrote: | * Otherwise, try again with ``._cfg0001_name``, then | ``._cfg0002_name`` and so on (base ten is used for the number part) | until a usable filename is found. | | For what purpose are the older cfg[number]_name files kept around? I | ask because I would anticipate the default behavior for replacing | configuration files with their pending updates to be picking the | newest update. That said, the previous versions would not serve a | purpose, or is there something I don't see? Existing tools ask the user which file they want to use when there's more than one. It's possible that this is more useful behaviour, especially if, say, someone is upgrading and downgrading the same package repeatedly for testing purposes. Personally, think the behaviour should be that it ensures a copy of the file winds up config protected; in other words, if a preexisting copy is already sitting in the config protected file stack (essentially), don't see any point to adding yet another file. Renaming to max + 1, or reusing the max if the match is the max is the match. Pkgcore doesn't *quite* do this (reuses any match), but shifting the file in the 'stack' makes more sense imo. ~harring pgpyG2juoxTI5.pgp Description: PGP signature
[gentoo-dev] compiz
Hi, Now, with the release of mesa 6.5.1 and the xorg-server-1.1.1-r1 ebuild we have a well-working aiglx-implementation in gentoo. I've now added a compiz-ebuild with patches for aiglx. I plan to add additional compiz-stuff (gset-compiz, quinn-versions of compiz etc.) soon. We could think of creating a new herd for compiz and stuff. People interested in helping out with compiz-packages can reply to me. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber: [EMAIL PROTECTED] pgpq5WcFoQeLN.pgp Description: PGP signature
[gentoo-dev] Re: compiz
Tach Hanno, 0x2B859DE3 (PGP-PK-ID) Hanno Böck schrieb: Now, with the release of mesa 6.5.1 and the xorg-server-1.1.1-r1 ebuild we have a well-working aiglx-implementation in gentoo. So Gnome 2.16 will use AIGLX in Metacity? V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: compiz
Christian 'Opfer' Faulhammer wrote: So Gnome 2.16 will use AIGLX in Metacity? Not by default. The support wasn't deemed 100% yet and thus slipped to 2.18. You can enabled it through a compiler flag, and Hanno's overlay exposes this through a USE flag. Be warned that a few people are having fairly large problems with it still. See https://bugs.freedesktop.org/show_bug.cgi?id=5999 and note that it doesn't just apply to the r300. Josh signature.asc Description: OpenPGP digital signature
[gentoo-dev] So long (but if anyone sends me fish...)
Well, kloeri marked me as retired today ( http://bugs.gentoo.org/show_bug.cgi?id=34058 ). I won't fight it this time... :) Its been a while since I contributed something, and I don't see myself doing anything anytime soon. I'm available at [EMAIL PROTECTED] if anyone needs anything. I wish you all the best! Nathaniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] So long (but if anyone sends me fish...)
Nathaniel McCallum wrote: Well, kloeri marked me as retired today ( http://bugs.gentoo.org/show_bug.cgi?id=34058 ). I won't fight it this time... :) Its been a while since I contributed something, and I don't see myself doing anything anytime soon. I'm available at [EMAIL PROTECTED] if anyone needs anything. I wish you all the best! Thanks for all your hard work on the beginnings of the installer. If you ever feel like coming back and being my bitc...err...re-joining the installer team, just let me know :) -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: compiz
Tach Joshua, 0x2B859DE3 (PGP-PK-ID) Joshua Baergen schrieb: Christian 'Opfer' Faulhammer wrote: So Gnome 2.16 will use AIGLX in Metacity? Not by default. The support wasn't deemed 100% yet and thus slipped to 2.18. No problem, I can wait. V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Sat, 16 Sep 2006 00:17:21 -0700 Brian Harring [EMAIL PROTECTED] wrote: | On Mon, Sep 11, 2006 at 11:22:11PM +0100, Ciaran McCreesh wrote: | Protected locations are determined by the ``CONFIG_PROTECT`` | environment variable, which is defined in the profiles and which | may be augmented or overridden by the current environment and user | configuration files. | | The user env override has no relevance to ebuilds relying on it, thus | doesn't have any business being mandated imo (it's implementation | choice, not requirement of ebuilds). Hrm, so installing env.d files that set CONFIG_PROTECT isn't reliable? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Package Manager Specification: configuration protection
On Sat, Sep 16, 2006 at 11:02:06PM +0100, Ciaran McCreesh wrote: On Sat, 16 Sep 2006 00:17:21 -0700 Brian Harring [EMAIL PROTECTED] wrote: | On Mon, Sep 11, 2006 at 11:22:11PM +0100, Ciaran McCreesh wrote: | Protected locations are determined by the ``CONFIG_PROTECT`` | environment variable, which is defined in the profiles and which | may be augmented or overridden by the current environment and user | configuration files. | | The user env override has no relevance to ebuilds relying on it, thus | doesn't have any business being mandated imo (it's implementation | choice, not requirement of ebuilds). Hrm, so installing env.d files that set CONFIG_PROTECT isn't reliable? Suspect you missed my point- Overriden by the current environment, aka the users environment at the time of executing $PKG_MANAGER). To build configurationm, portage stacks a bunch of mappings- the last one is the environment the script was ran in. In other words, CONFIG_PROTECT='' emerge blah # does disable CONFIG_PROTECT Portage allows CONFIG_PROTECT from the user env to override; that doesn't mean it's required for CONFIG_PROTECT support, which was the point. ~harring pgpEVkWjQkpmR.pgp Description: PGP signature
[gentoo-dev] punting old glibc ebuilds
since all our arches have managed to migrate to either glibc-2.3.6-r4 or glibc-2.4-r3, i'd like to go ahead and punt: glibc-2.3.3.20040420-r2.ebuild glibc-2.3.4.20040619-r2.ebuild glibc-2.3.4.20040808-r1.ebuild glibc-2.3.4.20041102-r1.ebuild glibc-2.3.4.20041102-r2.ebuild glibc-2.3.4.20050125-r1.ebuild glibc-2.3.5-r2.ebuild glibc-2.3.5-r3.ebuild glibc-2.3.6-r3.ebuild speak now ye arch weenies ! -mike pgp9IZ7IF7PY7.pgp Description: PGP signature
