Re: [gentoo-dev] Running a script to remove useless deps like virtual/libc from ebuilds
On Dec 30, 2007 6:50 PM, Petteri Räty [EMAIL PROTECTED] wrote: I have a script coming up that can remove virtual/libc dependencies from ebuilds automatically but can this be done safely for all ebuilds are are there ebuilds in system that really need this dep for stage building etc? FWIW: However, packages which are included in the system target, or are dependencies of system target packages, should generally include a complete dependency list (excluding bootstrap packages). This makes emerge -e system possible when installing from a stage 1 or stage 2 tarball. From the last paragraph on implicit dependencies in the devmanual at: http://devmanual.gentoo.org/general-concepts/dependencies/index.html Are there other deps to like this that could be removed? At least sys-libs/zlib could be one. I suppose all packages in /usr/portage/profiles/base/packages are suitable candidates. And maybe profile-specific implicit dependencies on profile-specific packages too, but those would be more complicated to locate. Denis.
Re: [gentoo-dev] USE flag documentation
I like the overall idea. I will comment the first proposed alternative as this is the one that makes the most sense in my opinion. Having one global use.xml where the default definitions are, and then using metadata.xml for each package to override the USE flag definition. With 's/default definitions/global USE flag definitions/' and 's/override the USE flag definition/define the local USE flags/' I would be even happier. Global USE flags should be defined in a central place and never be overridden. Local flags should be defined locally i.e. in the package subdirectory. I'd even go as far as adding that metadata.xml could include some clarifications/specifics/notes/warnings/whatever about a global USE flag for a given package, but that should not be a redefinition of the global USE flag. This would be appended by third party tools to complement the definition of the global USE flag in the context of that particular package. Problems with this approach include... * Easy to duplicate USE flags since we don't have a central repository for them. I'm not following you here. We'd have a central use.xml, so what do you mean ? And it's OK for local flags to be conflicting or duplicated since they're local. Lots of small files to go and parse to get the full picture of the tree. This can be cached. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] has_version etc parallelisability
On Mon, 31 Dec 2007 05:03:21 +0200 Petteri Räty [EMAIL PROTECTED] wrote: Ciaran McCreesh kirjoitti: Is it legal for ebuilds to call has_version and friends in parallel? Is it legal for ebuilds to call has_version and friends after the ebuild process has terminated? Discuss. Do you/anybody know if they are used in parallel in the tree at the moment? I can't see anything obvious, but that doesn't mean there aren't a few weird hiding cases. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] has_version etc parallelisability
On Sun, 30 Dec 2007 20:11:16 -0800 Alec Warner [EMAIL PROTECTED] wrote: On 12/30/07, Ciaran McCreesh [EMAIL PROTECTED] wrote: Is it legal for ebuilds to call has_version and friends in parallel? Is it legal for ebuilds to call has_version and friends after the ebuild process has terminated? Discuss. If the pm implements read/write locking on the underlying datastore (which it should probably have regardless of this request) then I don't see a problem in parallel has_version calls. Actually, it's the communication channel that's the issue... If, for example, has_version is implemented in terms of a request on a pipe rather than execing a new package manager, we get into messy bash locking territory... I don't get your second example..do you mean the ebuild is running has_version in the background and then terminating? Yeah. Again, consider the pipe example. If the package manager closes off the pipe when it thinks the ebuild's done, calling has_version will get the backgrounded process SIGPIPEd. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Sat, 22 Dec 2007 16:43:10 +0100 Piotr Jaroszyński [EMAIL PROTECTED] wrote: Hello, I have updated the GLEP, hopefully it is less confusing now and hence the discussion will be more technical. Still doesn't address my concerns, namely: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) - doesn't mention compability issues on the dev side (minor) Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Mon, 31 Dec 2007 15:33:51 +0100 Marius Mauch [EMAIL PROTECTED] wrote: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) That already happened with EAPI 1 and slot deps. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [GLEP] Use EAPI inside ebuild filename (.EAPI-ebuild of different?)
On Thu, 20 Dec 2007 15:50:02 +0300
Peter Volkov [EMAIL PROTECTED] wrote:
This hack is just to solve portage problem which does not ignore .ebuild
files which does not follow pkg-ver.ebuild syntax and suggested solution
is not the only solution. Other possibilities are, which I like more:
1. USE pkg-ver.EAPI-ebuild
Same thing really, just looks even messier IMO.
2. USE pkg-ver${EAPITAG}EAPI.ebuild
Here ${EAPITAG} is string to simplify parsing EAPI from
version. E.g. EAPITAG could be _eapi or EAPI or something
else.
Isn't backwards compatible in any way.
Marius
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] EAPI checking in eclasses
Is it legal for an eclass to check the EAPI version (presumably by using the EAPI variable) and perform some dependent behavior based on what it sees? I don't see any eclasses using EAPI for anything, so I'm curious. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 28 Dec 2007 23:34:44 + (UTC) Duncan [EMAIL PROTECTED] wrote: I understand the ban on non-EAPI-0 features in in-tree profiles, since users could be using old PMs, but it's fine using them in /etc/portage/*, provided one has upgraded to an appropriately compatible PM, correct? Yes (in case of portage). Marius -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Fri, 28 Dec 2007 12:03:12 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Thu, 27 Dec 2007 23:26:27 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Marius Mauch wrote: Nope. EAPI (from my POV) defines the API that a package manager has to export to an ebuild/eclass. That includes syntax and semantics of exported and expected functions and variables (IOW the content of ebuilds/eclasses), but does not contain naming and versioning rules (as those impact cross-package relationships). This restricted definition is ok for everybody? The restricted definition is certainly OK, but I'm not convinced that the restriction is necessary. There's no particular reason that new version formats can't be introduced in a new EAPI so long as the version strings don't appear in ebuilds using older EAPIs or in profiles. The issue is with comparison rules. For the current use case that's not an issue as it's simply a superset, so we could just use the new rules for everything. But if the rules are changed in an incompatible way, which rules would be used to compare version(EAPI_X) with version(EAPI_Y)? Ditto for naming rules. Those are even more of an issue, as they apply before we know the eventual EAPI (need to access the category/package directory before you can parse the ebuild filename) Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] EAPI checking in eclasses
On Mon, 31 Dec 2007 09:34:05 -0500 (EST) Caleb Tennis [EMAIL PROTECTED] wrote: Is it legal for an eclass to check the EAPI version (presumably by using the EAPI variable) and perform some dependent behavior based on what it sees? I don't see any eclasses using EAPI for anything, so I'm curious. Yes, so long as that dependent behaviour isn't intended to indicate an error. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 31 Dec 2007 15:46:06 +0100 Marius Mauch [EMAIL PROTECTED] wrote: The issue is with comparison rules. For the current use case that's not an issue as it's simply a superset, so we could just use the new rules for everything. But if the rules are changed in an incompatible way, which rules would be used to compare version(EAPI_X) with version(EAPI_Y)? You pretty much have to have a way of mapping an EAPI version onto an absolute version if you want to handle it sanely. Ditto for naming rules. Those are even more of an issue, as they apply before we know the eventual EAPI (need to access the category/package directory before you can parse the ebuild filename) Mmm, no. You have some concept of a superset of all supported naming rules, then refine once you've extracted the EAPI. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] USE flag documentation
Marius Mauch wrote: On Sun, 30 Dec 2007 19:54:04 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Let me know if you like any of those ideas, or if they all suck (and if they do, you better tell me why). I'm not sure which is the best way forward, which is why I want everyone to contribute towards the best solution moving forward. I really don't want to be stuck with something that is going to end up being a pain a year down the road. What benefit does use.xml have over use.desc? My opinion is that we should use use.desc for a complete list of use flags, including a generic description, allow a more verbose description in metadata.xml and get rid of the stupid separation of local and global flags. No need to change the format of use.desc though. I completely agree with this. This allows each individual package to provide more insight to what a USE flag does. The only benefit use.local.desc gives us is a fast way to list packages using some flags, but that's unreliable at best. If needed such a list could be autogenerated. Marius -- Doug Klima [EMAIL PROTECTED] http://dev.gentoo.org/~cardoe/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Monday 31 of December 2007 15:33:51 Marius Mauch wrote: Still doesn't address my concerns, namely: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) And what is the reason for not doing exactly that? Seems logical to me. And btw. slot deps added in EAPI 1 seems to have similiar impact, you can't use them in ebuilds using EAPI 0 nor in profiles/. - doesn't mention compability issues on the dev side (minor) Aren't new EAPIs introducing the same problem already? Devs should use up to date tools, and especially the devs running some checks on the whole tree. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] USE flag documentation
On Dec 31, 2007 3:30 PM, Marius Mauch [EMAIL PROTECTED] wrote: What benefit does use.xml have over use.desc? [...] No need to change the format of use.desc Anything that would enable us to document with more than a few words, which is what we're practically limited to with the current format of use.desc, would help. The currently available documentation on USE flags is clearly insufficient, maybe not for you and me and other devs, but for the majority of our users. Note that this is not the same as optionally adding more specific documentation on a global flag in the metadata.xml of a package. and get rid of the stupid separation of local and global flags Good idea. How do you plan to cope with the (currently) local USE flag conflicts though ? Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] USE flag documentation
Alec Warner [EMAIL PROTECTED] said: One of the GLEP's primary goals is to provide a global use flag definition and over-ride it with a local definition. How does putting all flags in use.desc and over-riding local flags in use.local.desc not accomplish this? It does, and maybe that's what we should use instead? The reason for the email is to figure out if what we have now is good enough, or if we should switch to something else. How does the glep intend to handle USE_EXPAND? It doesn't say anything about them right now, but since you brought it up...any ideas? :) -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpUIrolgzHPs.pgp Description: PGP signature
Re: [gentoo-dev] USE flag documentation
Doug Klima [EMAIL PROTECTED] said: Marius Mauch wrote: What benefit does use.xml have over use.desc? My opinion is that we should use use.desc for a complete list of use flags, including a generic description, allow a more verbose description in metadata.xml and get rid of the stupid separation of local and global flags. No need to change the format of use.desc though. I completely agree with this. This allows each individual package to provide more insight to what a USE flag does. This sounds sane to me as well. As I said, I'm just throwing ideas out there to see what sticks :) The only benefit use.local.desc gives us is a fast way to list packages using some flags, but that's unreliable at best. If needed such a list could be autogenerated. Completely agree. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpY4lku9pvmP.pgp Description: PGP signature
[gentoo-dev] RFC: brltty not starting early enough
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 All, brltty is one of our accessibility packages. It is a program that drives a braille display which is one way a blind person can access the computer. The project's guidelines for linux distributions at http://www.mielke.cc/brltty/guidelines.html suggest starting the program very early in the boot sequence. Ideally, I would like to be able to start brltty as soon as /dev is set up either with udev, devfs, or static. There is a new version of brltty which hasn't been put into portage yet, so I thought now would be a good time to ask about it. How should we set this up on gentoo? Any suggestions would be appreciated. Thanks, - -- William Hubbs gentoo accessibility team lead [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHeVYPblQW9DDEZTgRAqoSAJ9im3bK2aCniGcnyDEH7CKzNPQd9gCdGdaf j3ldKDZL5jSNy1FBZ7n7mqA= =In/i -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Mon, 31 Dec 2007 15:09:33 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 31 Dec 2007 15:46:06 +0100 Marius Mauch [EMAIL PROTECTED] wrote: The issue is with comparison rules. For the current use case that's not an issue as it's simply a superset, so we could just use the new rules for everything. But if the rules are changed in an incompatible way, which rules would be used to compare version(EAPI_X) with version(EAPI_Y)? You pretty much have to have a way of mapping an EAPI version onto an absolute version if you want to handle it sanely. Right, and that's likely to cause a mess in the long run IMO. Ditto for naming rules. Those are even more of an issue, as they apply before we know the eventual EAPI (need to access the category/package directory before you can parse the ebuild filename) Mmm, no. You have some concept of a superset of all supported naming rules, then refine once you've extracted the EAPI. Assuming the current package manager supports all used EAPIs, otherwise a formerly invalid name could still break it. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
On Mon, 31 Dec 2007 14:40:57 + Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 31 Dec 2007 15:33:51 +0100 Marius Mauch [EMAIL PROTECTED] wrote: - silently expands the scope of EAPI beyond ebuild contents (which is a blocker for me) That already happened with EAPI 1 and slot deps. Not really. Just because slot deps are included in EAPI 1 doesn't mean that they have to be supported everywhere. The complete atom specification should be a separate versioned document, and EAPI references version X of it and the profile specification references version Y, simple as that. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] USE flag documentation
On Mon, 31 Dec 2007 18:55:10 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: On Dec 31, 2007 3:30 PM, Marius Mauch [EMAIL PROTECTED] wrote: What benefit does use.xml have over use.desc? [...] No need to change the format of use.desc Anything that would enable us to document with more than a few words, which is what we're practically limited to with the current format of use.desc, would help. The currently available documentation on USE flags is clearly insufficient, maybe not for you and me and other devs, but for the majority of our users. Note that this is not the same as optionally adding more specific documentation on a global flag in the metadata.xml of a package. Most of the time when I see complaints about the description of USE flags (I'm fully aware of those) the issue isn't the format, just that noone else has come up with a better description. And technically use.desc isn't limited to a few words, unless you want to add multiple paragraphs with formatting, just the (current) presentation would get a bit ugly with longer descriptions. Of course the format could be changed if needed, but that needs a more specific description about the requirements. and get rid of the stupid separation of local and global flags Good idea. How do you plan to cope with the (currently) local USE flag conflicts though ? You mean different descriptions? Just use a placeholder in use.desc (like some global flags already have) and move the actual description in metadata.xml if there isn't any common base. Marius -- [EMAIL PROTECTED] mailing list
