[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.)
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Complicates the implementation (annoying), but more importantly negates one of the features of g55- being able to tell via the extension if the manager supports that EAPI. Honestly, the issue isn't breaking sourcing (literally unable to source it) of the ebuild as much as sourcing it *wrong*- simplest example, new metadata key is added in eapi 1.3, compliant implementations have to pull that key out of the env and put it in the cache. Sourcing on the surface, would succeed- but the results would be worthless (it'd basically be similar to the situation now). ~brian pgpeX8pilTQ8r.pgp Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Personally I don't see what the problem is with simply implementing GLEP-55. It's the best solution. It should be pretty simple to implement too. Certainly it wouldn't be anymore difficult to implement than your solution. Maybe once zmedico finishes his latest development push I will attempt to implement it.
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush: Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Yes, sure. I was just looking for a solution for the we have countless .eapi-X after 10 years problem. Personally I don't see what the problem is with simply implementing GLEP-55. It's the best solution. It should be pretty simple to implement too. Certainly it wouldn't be anymore difficult to implement than your solution. I fully agree. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller dev-z...@gentoo.org wrote: Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush: Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Yes, sure. I was just looking for a solution for the we have countless .eapi-X after 10 years problem. No one wants to be working with ebuild-29 or something like that in a few years and trying to figure out which feature came in which EAPI. Instead of bumping EAPI for each little change, save them up and bump no more than once a year or less, each bump bringing in some major new feature. With a little common sense and planning, we could make this a non-issue and give ebuild authors and PM devs alike a little time to get used to each change.
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 07:28:00PM +0900, Douglas Anderson wrote: On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller dev-z...@gentoo.org wrote: Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush: Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Yes, sure. I was just looking for a solution for the we have countless .eapi-X after 10 years problem. No one wants to be working with ebuild-29 or something like that in a few years and trying to figure out which feature came in which EAPI. Instead of bumping EAPI for each little change, save them up and bump no more than once a year or less, each bump bringing in some major new feature. With a little common sense and planning, we could make this a non-issue and give ebuild authors and PM devs alike a little time to get used to each change. There also is the angle that deploying g55 requires waiting at least a full stage release (~year, at least by the old standards) to ensure people aren't screwed by the repository changing formats (unversioned!) under their feet. I'd point out that g55 isn't even accepted (search the archives for the debates), but folks seem to be ignoring that and the issues of just flipping the switch... ~harring, aka the version the farking repo format so stuff like this can be done cleanly guy pgpo6FSu5I42q.pgp Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Tiziano Müller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Makes you getting to have to do the two stage source again AND you get another non obvious condition Should I bump the eapi internally or the filename? The main point again what is proposed in glep-55 is it that isn't invasive and non-transparent to users and developers. As stated in the analysis, the user side is already covered by the fact users use the cache, the developer side would require a two stage sourcing when committing to remain transparent. What we need to balance is if the invasive proposal is simpler than having a two stage sourcing done. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 02:21:33PM +0100, Luca Barbato wrote: Tiziano M??ller wrote: What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Makes you getting to have to do the two stage source again AND you get another non obvious condition Should I bump the eapi internally or the filename? The glep is quite clear on that point. The main point again what is proposed in glep-55 is it that isn't invasive and non-transparent to users and developers. It's not all that invasive. All that changes is that the EAPI goes at the end of the filename and you don't set it in the ebuild. Developers should be able to keep up with this, and if a user asks it's easy enough to say that it's a new version of ebuild, it has newer features see www.blah.org/blah for details. And really, users already ask what EAPI is so it's not that much headache. -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council - pgpb1wKek30va.pgp Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Brian Harring ferri...@gmail.com posted 20090223085232.ga6...@hrair, excerpted below, on Mon, 23 Feb 2009 00:52:32 -0800: On Mon, Feb 23, 2009 at 09:38:06AM +0100, Tiziano M??ller wrote: [quoting...] What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people[...] Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Complicates the implementation (annoying), but more importantly negates one of the features of g55- being able to tell via the extension if the manager supports that EAPI. That makes sense, but from my observation, the biggest resistance is coming from potentially unlimited changes to the extension. That rubs some people strongly enough the wrong way to have folks threatening to leave over it, etc. If it must be, it must be, but obviously, if there's a /reasonable/ way to avoid it, we should. Way back when this first came up, I asked a simple question and IIRC wasn't satisfied with the answer. Since the elements of it have been proposed separately, perhaps it's time to ask about the combination once again, as it seems to me to solve both the technical and aesthetic issues, tho admittedly it does have a bit of the complicates the implementation problem. As I understand it, the nastiest technical problem is currently the chicken/egg issue of needing the EAPI to source the ebuild... to /get/ the EAPI. Above, we have what amounts to a major/minor EAPI proposal, stick the major in the extension (or as a variant, the pre-extension filename), with it bumped only when the format changes enough to require pre-source knowledge of the change. Elsewhere, someone proposed strenthening the format rules by hard- specifying a location and format for the EAPI line, say line two of the ebuild and in a format specific enough to be parsed /without/ sourcing the ebuild, thus providing a pre-source method for grabbing the EAPI. The shoot-down when originally suggested was that this isn't flexible enough. It's also arguably less efficient since one has to access the file twice, first to get the EAPI, then to actually source the file. Unfortunately the below suggestion doesn't avoid that. Combining the two ideas, we get: Why not put the EAPI-major aka pre-parse-EAPI in that hard-specified in-file location, thus giving the package manager a method to grab it pre- source, then allow more flexibility on the EAPI-minor aka post-parse-EAPI? FWIW, all EAPIs to date have been EAPI-minor/post-parse, precisely /because/ of the need-the-EAPI-to-source-to-get-the-EAPI issue. This would eliminate that issue, providing both the necessary pre-source (major) EAPI solution and flexibility on the post-source (minor) EAPI. It would also avoid the so controversial aesthetic issue, maintaining the traditional .ebuild extension. The negative, however, as mentioned, is that of efficiency. It'd be necessary to access the file twice, pre-source to get the EAPI-major, then the source to fill in all the details. Putting just the EAPI-major in the filename/extension would avoid the first access (a dir listing would suffice) and using the filename for the EAPI entirely would in some cases possibly avoid accessing the file itself entirely -- at the expense of EAPI flexibility and aesthetics. Meanwhile, a status/process observation, if I may. Given the efficiency negative of putting the EAPI anywhere /but/ the filename and the way the debate has gone, GLEP-55 or something close to it (using the filename for EAPI) would appear headed toward ultimate approval, however slow it seems to be getting there. The major blocker would appear to be that the GLEP as-is simply doesn't sufficiently address everything that has come up in the discussions. As such, it's not clearly and sufficiently enough worded for the council to feel comfortable approving it. Based on council logs and discussion, I get the STRONG impression that they are pretty much /begging/ the proponents to address this issue, updating the GLEP as appropriate, so they can /finally/ get out of the eternal debate stage and vote it up or down (presumably up as it doesn't appear they have a viable alternative either) on its merits, and the PMs can get it implemented and both the council and Gentoo can move on. Unfortunately, due to personnel issues, apparently there's currently nobody filling the triple qualifications of being (1) a strong enough proponent to bother, (2) a PM dev or other with sufficient grasp of the issues to actually /do/ the work, and (3) a Gentoo dev with the necessary
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 04:26:49 -0800 Brian Harring ferri...@gmail.com wrote: There also is the angle that deploying g55 requires waiting at least a full stage release (~year, at least by the old standards) to ensure people aren't screwed by the repository changing formats (unversioned!) under their feet. No it doesn't. It's transparent to users using an older package manager. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Fwd: News item: Generation 1 deprecation
See the patch. -- cd /local/pub more beer /dev/mouth --- generation1-deprecation.orig2009-02-23 14:50:37.920591164 +0100 +++ generation1-deprecation 2009-02-23 14:51:25.180617090 +0100 @@ -21,9 +21,9 @@ emerge -av --depclean virtual/jdk:1.4 -If don't need virtual/jdk:1.4 any more then you can remove the +If you don't need virtual/jdk:1.4 any more then you can remove the individual JDKs. First get the list of installed JDKs with -eselect and then remove with depclean, for example: +eselect and then remove those that are not needed anymore with depclean, for example: eselect java-vm list emerge -av --depclean sun-jdk:1.4 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 03:15:03 +0100 Luca Barbato lu_z...@gentoo.org wrote: Let's try to start with a common workflow for the user: - an user with an ancient version of portage syncs - it requires a package - it looks at the cache ($portdir/metadata/cache/) - picks the best entry from the ones showing an eapi it understands - keeps going. Apparently we do not have any issue... ...assuming the metadata cache is valid. That isn't always the case. 2- The user will get unpredictable behavior, but portage tell you when upgrading is needed... Not if the version you'd need to do metadata generation is ~arch it doesn't. 3- you'd have to disable them Yes, tell everyone to disable all the overlays that make use of a few features only in ~arch package managers... That'll work... In this case we have a problem if the source step is a single one, portage won't know in advance how to behave. So the first step has to be split in two: - first portage discovers which is the eapi version ...which it can't do, because it doesn't know the EAPI. The problem is that right now sourcing is done by having an instructed bash. So the simplest way to get the first step done is parsing the ebuild file with something different like file(1) and then instruct bash and do the parsing. file(1) can't parse ebuilds. Only an ebuild implementation can parse ebuilds, and only if it already knows the EAPI. What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. There's no surprise at all. It's extremely clear. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 01:50:10PM +, Ciaran McCreesh wrote: On Mon, 23 Feb 2009 04:26:49 -0800 Brian Harring ferri...@gmail.com wrote: There also is the angle that deploying g55 requires waiting at least a full stage release (~year, at least by the old standards) to ensure people aren't screwed by the repository changing formats (unversioned!) under their feet. No it doesn't. It's transparent to users using an older package manager. Would be useful if someone pulled older portage versions and checked exactly what they do in this case- explode, behave, etc (manifest behaviour included). It's been several years, but I recall portage having problems at the onset of EAPI w/ it. Beyond that, what I was stating was that the user doesn't get told sorry, your manager is too old, upgrade- kind of an unobvious failing. Frankly, in terms of g55 I don't particularly care if it were implemented- although I'd rather see it go in a seperate repo along w/ the dozen other fixups needed, preferably starting w/ overlays... ~harring pgplVR5glWTvH.pgp Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 06:15:25 -0800 Brian Harring ferri...@gmail.com wrote: No it doesn't. It's transparent to users using an older package manager. Would be useful if someone pulled older portage versions and checked exactly what they do in this case- explode, behave, etc (manifest behaviour included). It's been several years, but I recall portage having problems at the onset of EAPI w/ it. It was checked back when 55 was originally written. If it's broken now, it's a breakage since then... Frankly, in terms of g55 I don't particularly care if it were implemented- although I'd rather see it go in a seperate repo along w/ the dozen other fixups needed, preferably starting w/ overlays... Well yes, but that's never realistically going to happen. 55's one of the few repository format fixes that can happen in a reasonable timeframe. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Douglas Anderson wrote: No one wants to be working with ebuild-29 or something like that in a few years and trying to figure out which feature came in which EAPI. Instead of bumping EAPI for each little change, save them up and bump no more than once a year or less, each bump bringing in some major new feature. I got the impression that if anything there is a desire to allow EAPIs to change more offen, and not less. And these changes could become more dramatic. I'm not sure this is actually a bad thing (within reason - we do need to have clear specifications for anything that hits production so that we don't have a package manager mess). Also - keep in mind that EAPIs do not need to be numbers and are not ordered. You could have ebuild-i_am_a_furry_monkey or ebuild-bunch-of-stuff-in-unicode-that-maybe-your-terminal-displays. Sure - hopefully the names will be more sensible and somewhat uniform, but we're not necessarily just talking about adding a number to the extension. I still don't see why we need to be encoding metadata in filenames. PERL doesn't care what a file extension is, python doesn't care, bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so doesn't care. I'm sure that in at least some of these cases they end up parsing parts of the file twice - once to figure out what it is, and the second time to actually handle it. I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. This seems to me to be a solved problem. You put a header in a file that tells you how to read the file. Headers are split into fields and if a program doesn't know what to do with a field it ignores it (or if the header so instructs it doesn't even try to parse the file). This should be easy to do and keep the file bash-compatible. Just stick a comment line close to the top of the file and put whatever you want on it. You could also stick something in metadata.xml (although this makes working with ebuilds outside of a repository more difficult). You run the file through an algorithm to find out what the EAPI is, and then source it if appropriate. Sure, if you make some major change analogous to switching from the .rpm to the .deb package format then maybe an extension change would make sense. But, why expose the inner workings of the package file format to the filesystem?
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 09:28:06 -0500 Richard Freeman ri...@gentoo.org wrote: I got the impression that if anything there is a desire to allow EAPIs to change more offen, and not less. And these changes could become more dramatic. But we're still only talking maybe three new EAPIs a year. Also - keep in mind that EAPIs do not need to be numbers and are not ordered. You could have ebuild-i_am_a_furry_monkey or ebuild-bunch-of-stuff-in-unicode-that-maybe-your-terminal-displays. Sure - hopefully the names will be more sensible and somewhat uniform, but we're not necessarily just talking about adding a number to the extension. You're using developers might do something really stupid as an argument? By that logic, the current setup sucks since someone might make an EAPI called a'bc\d , so developers might have to put weird escaping in when specifying EAPI. Also note that kdebuild went with .kdebuild-1, not .ebuild-kdebuild-1. It's no leap to have slightly different extension rules for any project that creates its own non-numerical EAPIs. I still don't see why we need to be encoding metadata in filenames. Because the metadata has to be known before the file can be used. PERL doesn't care what a file extension is, python doesn't care, bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so doesn't care. I'm sure that in at least some of these cases they end up parsing parts of the file twice - once to figure out what it is, and the second time to actually handle it. I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. Back when Perl 5 and PHP 5 were new, people often used extensions like .php4 and .php5 to tell their webserver how to handle scripts... This seems to me to be a solved problem. You put a header in a file that tells you how to read the file. Headers are split into fields and if a program doesn't know what to do with a field it ignores it (or if the header so instructs it doesn't even try to parse the file). This should be easy to do and keep the file bash-compatible. Just stick a comment line close to the top of the file and put whatever you want on it. That doesn't work with existing packages or existing package managers. Sure, if you make some major change analogous to switching from the .rpm to the .deb package format then maybe an extension change would make sense. But, why expose the inner workings of the package file format to the filesystem? For the same reason versions and package names are already in the filename. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Mon, 23 Feb 2009 03:15:03 +0100 Luca Barbato lu_z...@gentoo.org wrote: Let's try to start with a common workflow for the user: - an user with an ancient version of portage syncs - it requires a package - it looks at the cache ($portdir/metadata/cache/) - picks the best entry from the ones showing an eapi it understands - keeps going. Apparently we do not have any issue... ...assuming the metadata cache is valid. That isn't always the case. When it isn't? 2- The user will get unpredictable behavior, but portage tell you when upgrading is needed... Not if the version you'd need to do metadata generation is ~arch it doesn't. ... 3- you'd have to disable them Yes, tell everyone to disable all the overlays that make use of a few features only in ~arch package managers... That'll work... disable overlays to UPGRADE to the new portage. Not rocket science... In this case we have a problem if the source step is a single one, portage won't know in advance how to behave. So the first step has to be split in two: - first portage discovers which is the eapi version ...which it can't do, because it doesn't know the EAPI. If you are generating the cache you must have a way to know it... The problem is that right now sourcing is done by having an instructed bash. So the simplest way to get the first step done is parsing the ebuild file with something different like file(1) and then instruct bash and do the parsing. file(1) can't parse ebuilds. file parses quite well avi and mov, ebuild will be anytime more complex than that right? Anyway it isn't a problem since the version of portage doing the work is supposed to be up to date, if isn't it will be updated first using the normal user workflow that has already been covered by the cache. Only an ebuild implementation can parse ebuilds, and only if it already knows the EAPI. That is always the case since you are adding an ebuild and you are supposed to have an up to date portage in order to do that. What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. There's no surprise at all. It's extremely clear. Not that much. lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 15:46:24 +0100 Luca Barbato lu_z...@gentoo.org wrote: Apparently we do not have any issue... ...assuming the metadata cache is valid. That isn't always the case. When it isn't? Every now and again (probably after someone changes eutils...), rsync mirrors end up shipping a load of stale metadata for parts of the tree. Portage users probably don't notice, since it just causes a slowdown. disable overlays to UPGRADE to the new portage. Not rocket science... No no. You're forcing people to switch to ~arch to be able to use overlays. In this case we have a problem if the source step is a single one, portage won't know in advance how to behave. So the first step has to be split in two: - first portage discovers which is the eapi version ...which it can't do, because it doesn't know the EAPI. If you are generating the cache you must have a way to know it... No, we don't. That's the entire frickin' point of GLEP 55, and one that you would do well to understand fully before commenting further. The way we generate metadata now is massively horrible, and only works because there aren't any serious global scope differences between EAPIs. We can't make any global scope changes to future EAPIs because it breaks current metadata generation. Right now it's safe to pretend EAPI 0 until the real EAPI is worked out, but that won't hold in the future -- as soon as global scope changes come along, there's no safe EAPI that can be assumed, even if we didn't have to worry about breaking existing package managers. The problem is that right now sourcing is done by having an instructed bash. So the simplest way to get the first step done is parsing the ebuild file with something different like file(1) and then instruct bash and do the parsing. file(1) can't parse ebuilds. file parses quite well avi and mov, ebuild will be anytime more complex than that right? It's already *way* more complicated than that. Extracting metadata requires a full bash 3 implementation along with a considerable amount of supporting code. Anyway it isn't a problem since the version of portage doing the work is supposed to be up to date, if isn't it will be updated first using the normal user workflow that has already been covered by the cache. Most users don't run ~arch, and do use overlays. So no, this will affect normal user workflow. Only an ebuild implementation can parse ebuilds, and only if it already knows the EAPI. That is always the case since you are adding an ebuild and you are supposed to have an up to date portage in order to do that. Again, you're not getting it. Doesn't matter how up to date your package manager is. You can't find out the EAPI unless you already know the EAPI. What is proposed in glep-55 seems to aim to solve both issues at the same time (it isn't stated) by switching file extension every time the eapi is changed. This is slightly against the principle of the least surprise and apparently is disliked by enough people to lead the situation to be discussed in the council. There's no surprise at all. It's extremely clear. Not that much. How is '.ebuild-3' being used to specify version 3 of the ebuild format in the least bit surprising? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Richard Freeman wrote: I still don't see why we need to be encoding metadata in filenames. PERL doesn't care what a file extension is, python doesn't care, bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so doesn't care. I'm sure that in at least some of these cases they end up parsing parts of the file twice - once to figure out what it is, and the second time to actually handle it. I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. I have to admit I'm in the same camp with Richard, and don't understand the necessity. I'm also opposed to creating arbitrary suffixes to the ebuild extension, for cosmetic and compatibility reasons. Plus, I don't really grasp the whole we have to source the whole ebuild to know the EAPI version argument. It's one variable, in one line. Can't a simple parser get that and go from there? Steve
Re: [gentoo-dev] Should that file be a License ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mounir Lamouri wrote:
Hi,
I was writing a trivial version bump for net-voip/gnugk-2.2.8 (bug
#258518) but upstream added a file named p2pnat_license.txt (see
http://dpaste.com/123376/) This file looks to authorize gnugk project
(and users) to use p2pnat technology. gnugk is already licensed under
GPL-2 and I was wondering if this new file should be considered as
another license and if it has to be in the LICENSE line ? In this case,
should the file be added like he is in the gnugk tarball or should it be
templatized like most licenses ?
Thanks,
Mounir
That paste is gone/expired.
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmixHYACgkQp/VmCx0OL2wURgCff8WSLE9PHXfO/HI+GdrE1W3J
0/kAoLpB4oFEwOx5Dk+ceo70vCueZgbk
=hKRC
-END PGP SIGNATURE-
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
line. Can't a simple parser get that and go from there?
Not true. This is entirely legal:
In pkg-1.ebuild:
EAPI=${PV}
printf -v EAPI '%s' 4
inherit foo
EAPI=2
In foo.eclass:
EAPI=3
And in this case, the package manager has to know that EAPI=2, and it
has to use EAPI 2's behaviour for performing the inherit.
In fact, it gets worse if you consider that future EAPIs will probably
allow per-package eclasses. So you could end up with this crazy
situation:
In pkg-1.ebuild:
require pkg
In cat/pkg/pkg.eclass:
EAPI=3
In global pkg.eclass:
EAPI=2
So here you can't even use a faked pre-source EAPI. If you assume EAPI
0 beforehand, the global pkg.eclass will be used, so EAPI will end up
as 2. But if you assume EAPI 3 beforehand, the per-pkg eclass will be
used, so the EAPI will end up as 3.
It gets even crazier if you put EAPI=2 in the per-pkg eclass and
EAPI=3 in the global one instead...
And whilst this is clearly a deliberate example of how to create
craziness, the only difference between this and the real world is that
the craziness is obvious here. The current rules really are this
complicated, and we can't retroactively fix them.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] Should that file be a License ?
On Mon, Feb 23, 2009 at 10:44 AM, Marijn Schouten (hkBst)
hk...@gentoo.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mounir Lamouri wrote:
Hi,
I was writing a trivial version bump for net-voip/gnugk-2.2.8 (bug
#258518) but upstream added a file named p2pnat_license.txt (see
http://dpaste.com/123376/) This file looks to authorize gnugk project
(and users) to use p2pnat technology. gnugk is already licensed under
GPL-2 and I was wondering if this new file should be considered as
another license and if it has to be in the LICENSE line ? In this case,
should the file be added like he is in the gnugk tarball or should it be
templatized like most licenses ?
Thanks,
Mounir
That paste is gone/expired.
Marijn
- --
Sarcasm puts the iron in irony, cynicism the steel.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
http://www.gentoo.org/proj/en/lisp/, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkmixHYACgkQp/VmCx0OL2wURgCff8WSLE9PHXfO/HI+GdrE1W3J
0/kAoLpB4oFEwOx5Dk+ceo70vCueZgbk
=hKRC
-END PGP SIGNATURE-
I attached it to this email.
Mounir
P2Pnat Technology license (H.460.23/24)
In relation to any work derived from the Point to Point through NAT
Specification
(P2Pnat Technology), International Secure Virtual offices (Asia) Pte Ltd
ISVO
(together with his successors and assignees) will grant a royalty-free,
non-exclusive license with reciprocity to Qualified Parties to use the P2Pnat
Technology
solely to the extent necessary to implement and practice such as in compliance
with the
P2Pnat Specification. As used herein, Qualified Parties means a party who has
not,
does not and will not assert, in litigation or otherwise, including in
licensing discussions,
any patent or other intellectual property right against ISVO of any nature. Any
license to
a Qualified Party shall terminate at once if such party: (a) asserts a patent
or other
intellectual property right against ISVO as set forth above; or (b) if
applicable,
fails to properly implement the disclosure flag described in the P2Pnat
Specification
in a truthful manner. This license also extends to cover users and furthur
development
of the licensee's implementation only as far as the use does not violate the
licensee's
own licensing terms and conditions, where apon a user is in breach of the
licensee's license
then they shall be deemed to be breach of this license. ISVO will grant
non-exclusive licenses
to Non-Qualified Parties on reasonable and reciprocal terms and conditions.
The GnuGk project (www.gnugk.org) is hereby granted non-exclusive royalty-free
license of
Point to Point through NAT (P2Pnat Technology) to be used with the GnuGk
project.
Users and developers of GnuGk are hereby also granted non-exclusive
royalty-free license of
P2Pnat Technology as long as the use of GnuGk and/or any derived work
containing this technology
is used and/or issued under the same terms and conditions as the GnuGk project.
Failure to comply
with the GnuGk license shall automatically be deemed a violation of this
license.
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 08:43:09 -0700 Steve Dibb bean...@gentoo.org wrote: Plus, I don't really grasp the whole we have to source the whole ebuild to know the EAPI version argument. It's one variable, in one line. Can't a simple parser get that and go from there? The problem is that its technically allowed for the value of $EAPI to be dependent on other bits and pieces. For instance: if [[ $PV = 2.6 ]] then EAPI=2 else EAPI=1 fi The quick-n-dirty solution to that is to just say that EAPI is not just a bash variable, it's also a magic string, so manipulating it in bash is forbidden. And please place it in line 5 of your ebuild, kthxbye. To be honest I see no good reason for allowing manipulation of it, but I'm sure other people will tell me why adding this requirement at this point is wrong even though no ebuilds in the tree to the best of my knowledge use EAPI as anything more than a declaration that's placed Just before inherit, right after the header. /loki_val
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 17:06:17 +0100 Peter Alfredsen loki_...@gentoo.org wrote: To be honest I see no good reason for allowing manipulation of it, but I'm sure other people will tell me why adding this requirement at this point is wrong There's not really a good reason to allow manipulating it (and, obviously, with GLEP 55 manipulating it becomes impossible), but since for all current EAPIs it's just defined as a metadata variable that's generated in the same way as things like SLOT, manipulating it is unfortunately legal. even though no ebuilds in the tree to the best of my knowledge use EAPI as anything more than a declaration that's placed Just before inherit, right after the header. People have, in the past, set EAPI inside eclasses. It's stupid and horrible, but they've done it. But here's the thing -- even if we retroactively enforce a new rule requiring it to be specified in a particular way right after the header (which is bad, since it breaks things people have already done), it *still* doesn't let us change global scope behaviour since current package managers don't extract EAPI the horrid way. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 15:53:20 +
Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in
one line. Can't a simple parser get that and go from there?
Not true. This is entirely legal:
In pkg-1.ebuild:
EAPI=${PV}
printf -v EAPI '%s' 4
inherit foo
EAPI=2
Which begs the question: is it really worth allowing it?
If we only allow constant assignments (which is an implicit restriction
in the file extension version) then this can be parsed easily with
grep/tr/awk/etc and can be the magic eapi guessing. Of course the tree
has to be checked before implementing this and we'll have to wait a
good amount of time before breaking the current eapi bash-parsing but
I'm not aware of any eapi proposal that would break the current behavior
and would be usable in the main tree within a reasonable amount of
time such that we can't ignore backward compatibility.
In foo.eclass:
EAPI=3
I thought this was prohibited.
Alexis.
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 17:13:16 +0100 Alexis Ballier aball...@gentoo.org wrote: Which begs the question: is it really worth allowing it? If we only allow constant assignments (which is an implicit restriction in the file extension version) then this can be parsed easily with grep/tr/awk/etc and can be the magic eapi guessing. Of course the tree has to be checked before implementing this and we'll have to wait a good amount of time before breaking the current eapi bash-parsing but I'm not aware of any eapi proposal that would break the current behavior and would be usable in the main tree within a reasonable amount of time such that we can't ignore backward compatibility. ...and then we have to do the whole thing again every time something new crops up. EAPI was supposed to solve this, and profile eapi and GLEP 55 finish the job. Repeatedly going back and saying oh, we have to wait another year or more again is unacceptable. In foo.eclass: EAPI=3 I thought this was prohibited. It's legal, and people have done it, but it's considered by most people to be a horrible QA violation. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 16:19:56 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 23 Feb 2009 17:13:16 +0100 Alexis Ballier aball...@gentoo.org wrote: Which begs the question: is it really worth allowing it? If we only allow constant assignments (which is an implicit restriction in the file extension version) then this can be parsed easily with grep/tr/awk/etc and can be the magic eapi guessing. Of course the tree has to be checked before implementing this and we'll have to wait a good amount of time before breaking the current eapi bash-parsing but I'm not aware of any eapi proposal that would break the current behavior and would be usable in the main tree within a reasonable amount of time such that we can't ignore backward compatibility. ...and then we have to do the whole thing again every time something new crops up. Please give an example because I fail to see how. EAPI was supposed to solve this, and profile eapi and GLEP 55 finish the job. Repeatedly going back and saying oh, we have to wait another year or more again is unacceptable. Had we found a compromise at the beginning of glep55, that extra year would be over by now... Alexis. signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 17:48:27 +0100 Alexis Ballier aball...@gentoo.org wrote: ...and then we have to do the whole thing again every time something new crops up. Please give an example because I fail to see how. New version suffix rules. New bash versions. New package naming rules. Partially composable EAPIs. Tree-provided internals. Consistent variable namespacing. Metadata via function calls. EAPI was supposed to solve this, and profile eapi and GLEP 55 finish the job. Repeatedly going back and saying oh, we have to wait another year or more again is unacceptable. Had we found a compromise at the beginning of glep55, that extra year would be over by now... And we'd be starting on the next batch of oh, we need to wait another year. Had GLEP 55's necessity been accepted a year ago, we'd have a whole bunch of requested features implemented by now. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 7:53 AM, Ciaran McCreesh
ciaran.mccre...@googlemail.com wrote:
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
line. Can't a simple parser get that and go from there?
Not true. This is entirely legal:
In pkg-1.ebuild:
EAPI=${PV}
printf -v EAPI '%s' 4
inherit foo
EAPI=2
In foo.eclass:
EAPI=3
This is not legal, the devmanual[1] explicitly states that it is not
legal to set EAPI in an eclass. If it was you would have an open and
shut case for g55 (since you could set EAPI based on PV in an eclass
and then inherit the eapi; requiring a bash parser). But its illegal,
which makes your argument harder.
A bad argument is EAPI based on some PV logic that you can copy across
ebuilds that differ by version; which would fall into 'stupid' in my
book.
[1] http://devmanual.gentoo.org/ebuild-writing/eapi/index.html
And in this case, the package manager has to know that EAPI=2, and it
has to use EAPI 2's behaviour for performing the inherit.
In fact, it gets worse if you consider that future EAPIs will probably
allow per-package eclasses. So you could end up with this crazy
situation:
In pkg-1.ebuild:
require pkg
In cat/pkg/pkg.eclass:
EAPI=3
In global pkg.eclass:
EAPI=2
Also illegal, but I assume here you intend to change the legality of
things in your weird future example.
So here you can't even use a faked pre-source EAPI. If you assume EAPI
0 beforehand, the global pkg.eclass will be used, so EAPI will end up
as 2. But if you assume EAPI 3 beforehand, the per-pkg eclass will be
used, so the EAPI will end up as 3.
It gets even crazier if you put EAPI=2 in the per-pkg eclass and
EAPI=3 in the global one instead...
And whilst this is clearly a deliberate example of how to create
craziness, the only difference between this and the real world is that
the craziness is obvious here. The current rules really are this
complicated, and we can't retroactively fix them.
--
Ciaran McCreesh
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 11:02:17 -0800 Alec Warner anta...@gentoo.org wrote: In foo.eclass: EAPI=3 This is not legal, the devmanual[1] explicitly states that it is not legal to set EAPI in an eclass. That's purely a QA thing, and it only applies to repositories that follow Gentoo's QA rules. It's in the same category as rules about what indenting style to use, not rules about how variables are formatted. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 08:43:09 -0700
Steve Dibb bean...@gentoo.org wrote:
Richard Freeman wrote:
I still don't see why we need to be encoding metadata in filenames.
PERL doesn't care what a file extension is, python doesn't care,
bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even
ld-linux.so doesn't care. I'm sure that in at least some of these
cases they end up parsing parts of the file twice - once to figure
out what it is, and the second time to actually handle it. I'm
actually hard pressed to think of any unix-based software that uses
the filename to store a mandatory file format versioning specifier
of some kind.
$ ls /usr/lib
I have to admit I'm in the same camp with Richard, and don't
understand the necessity. I'm also opposed to creating arbitrary
suffixes to the ebuild extension, for cosmetic and compatibility
reasons.
Plus, I don't really grasp the whole we have to source the whole
ebuild to know the EAPI version argument. It's one variable, in one
line. Can't a simple parser get that and go from there?
Not really. Let's play Guess the EAPI. :o
1.
-
EAPI=1
2. (with myeclass.eclass containing EAPI=2)
-
EAPI=1
inherit myeclass
-
3. (with myeclass.eclass containing EAPI=2)
-
EAPI=5
inherit myeclass
-
1. 1 (simple enough)
2. 2 (because myeclass.eclass sets EAPI=2)
3. 5 (inherit was changed in EAPI 5 to not overwrite ${EAPI} if
already set in an ebuild)
So you see, it's not as easy as a grep command. You need to source the
ebuild to know how things like inherit will affect the environment.
And without knowing the EAPI, you don't know which version of inherit to
call.
(i hope i have this right. feel free to call me names if i don't)
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Mon, 23 Feb 2009 17:48:27 +0100 Alexis Ballier aball...@gentoo.org wrote: ...and then we have to do the whole thing again every time something new crops up. Please give an example because I fail to see how. New version suffix rules. New bash versions. New package naming rules. Partially composable EAPIs. Tree-provided internals. Consistent variable namespacing. Metadata via function calls. EAPI was supposed to solve this, and profile eapi and GLEP 55 finish the job. Repeatedly going back and saying oh, we have to wait another year or more again is unacceptable. Had we found a compromise at the beginning of glep55, that extra year would be over by now... And we'd be starting on the next batch of oh, we need to wait another year. Had GLEP 55's necessity been accepted a year ago, we'd have a whole bunch of requested features implemented by now. I doubt Portage would have gained new features any faster. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 21:30:04 +0200 Petteri Räty betelge...@gentoo.org wrote: And we'd be starting on the next batch of oh, we need to wait another year. Had GLEP 55's necessity been accepted a year ago, we'd have a whole bunch of requested features implemented by now. I doubt Portage would have gained new features any faster. Some useful things that are currently difficult become a lot easier to implement with GLEP 55. Per-package eclasses, for example, are easy if you don't have to care about the upgrade path, as is replacing versionator with a package manager internal. The complexity for both of those is in the upgrade path, not the implementation. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: bzr.eclass
Hi, Ulrich Mueller u...@gentoo.org: On Fri, 20 Feb 2009, Christian Faulhammer wrote: $ time (bzr diff --old lp:bzr-gentoo-overlay \ --new /media/disk/bzr-overlay/|diffstat) real0m50.088s This is prohibitive. Drop it completely, or enable it only if some environment variable is set. Dropped completely in my branch. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: bzr.eclass
Hi,
René 'Necoro' Neumann li...@necoro.eu:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jorge Manuel B. S. Vicetto schrieb:
Hi.
Christian Faulhammer wrote:
Hi,
a user maintained a Bazaar overlay for some time now and introduced
some changes to bzr eclass, I would like to introduce into the
tree. Please review the attached patch.
V-Li
I'm attaching a revised patch that tries to improve some issues in
the current version in the tree, incorporates your changes and Peter
Volkov's (pva) patch about sftp URIs.
if [[ ${EBZR_REPO_URI} == */* ]]; then
repository=${EBZR_REPO_URI}/${EBZR_BRANCH}
elif [[ -n ${EBZR_BRANCH} ]] ; then
...
else
...
fi
If I see this correctly, this appends EBZR_BRANCH if there is a slash
in the REPO_URI ... what kind of guess is this supposed to be? I
think, the second test (append iff EBZR_BRANCH is set) should be
sufficient.
Not sure, though I will investigate (and likely drop it).
V-Li
--
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
URL:http://www.faulhammer.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ryan Hill wrote: On Mon, 23 Feb 2009 08:43:09 -0700 Steve Dibb bean...@gentoo.org wrote: Richard Freeman wrote: I still don't see why we need to be encoding metadata in filenames. PERL doesn't care what a file extension is, python doesn't care, bzip2 doesn't care, tar doesn't care, gzip doesn't care, and even ld-linux.so doesn't care. I'm sure that in at least some of these cases they end up parsing parts of the file twice - once to figure out what it is, and the second time to actually handle it. I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. $ ls /usr/lib ldconfig ? I have to admit I'm in the same camp with Richard, and don't understand the necessity. I'm also opposed to creating arbitrary suffixes to the ebuild extension, for cosmetic and compatibility reasons. Plus, I don't really grasp the whole we have to source the whole ebuild to know the EAPI version argument. It's one variable, in one line. Can't a simple parser get that and go from there? Not really. Let's play Guess the EAPI. :o 1. - EAPI=1 2. (with myeclass.eclass containing EAPI=2) - EAPI=1 inherit myeclass Invalid - 3. (with myeclass.eclass containing EAPI=2) - EAPI=5 inherit myeclass Invalid So you see, it's not as easy as a grep command. You need to source the ebuild to know how things like inherit will affect the environment. And without knowing the EAPI, you don't know which version of inherit to call. It it isn't invalid already... (i hope i have this right. feel free to call me names if i don't) Names! lu -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 21:51:11 +0100 Luca Barbato lu_z...@gentoo.org wrote: 2. (with myeclass.eclass containing EAPI=2) - EAPI=1 inherit myeclass Invalid QA violation, but legal and a pain in the ass. 3. (with myeclass.eclass containing EAPI=2) - EAPI=5 inherit myeclass Invalid QA violation, but legal and a pain in the ass. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 20:54:38 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 23 Feb 2009 21:51:11 +0100 Luca Barbato lu_z...@gentoo.org wrote: 2. (with myeclass.eclass containing EAPI=2) - EAPI=1 inherit myeclass Invalid QA violation, but legal and a pain in the ass. I didn't think it was a brainy thing to do, but I can't find anything saying it isn't allowed. It probably shouldn't be. 3. (with myeclass.eclass containing EAPI=2) - EAPI=5 inherit myeclass Invalid QA violation, but legal and a pain in the ass. Can we ban eclasses from setting EAPI? Is there any case where it would be sane? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 16:15:25 -0600 Ryan Hill dirtye...@gentoo.org wrote: Can we ban eclasses from setting EAPI? Is there any case where it would be sane? It's already banned from a QA perspective, but from a package manager perspective people have done it in the past and possibly still do do it, and the spec doesn't forbid it. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 16:15:25 -0600 Ryan Hill dirtye...@gentoo.org wrote: On Mon, 23 Feb 2009 20:54:38 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Mon, 23 Feb 2009 21:51:11 +0100 Luca Barbato lu_z...@gentoo.org wrote: 2. (with myeclass.eclass containing EAPI=2) - EAPI=1 inherit myeclass Invalid QA violation, but legal and a pain in the ass. I didn't think it was a brainy thing to do, but I can't find anything saying it isn't allowed. It probably shouldn't be. Ah now i did. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] [RFC] global useflags
server15 custom-cflags 10 logrotate 9 gsm 9 semantic-desktop 9 webkit8 html 7 multislot 7 nautilus 7 audacious 7 demo 7 editor6 sound 6 phonon6 tools 6 pango 6 dbi 6 qt3support6 dxr3 6 web 6 net 5 music 5 smtp 5 irc 5 policykit 5 mp4 5 clisp 5 spamassassin 5 serial5 nfs 5 midi 5 pcsc-lite 5 zvbi 5 http 5 proposals: custom-cflags: Build with user-specified CFLAGS (unsupported) as custom-cxxflags has been added (w/o discussion here) semantic-desktop: Semantic desktop allows for storage of digital information and its metadata to allow the user to express his personal mental models, making all in formation become intuitively accessible still pending is the global gsm useflag, no answer so far from the mobile herd in bug #254677. Markus signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] global useflags
Markus Meier mae...@gentoo.org writes:
semantic-desktop: Semantic desktop allows for storage of digital
information and its metadata to allow the user to express his personal
mental models, making all in formation become intuitively accessible
I find this description pretty content-free and hand-wavy. I usually
care to know what the concrete effect of a use flag is, to know if it's
something I want to enable, in terms of features provided and the
dependencies implied.
To that end, please allow me to suggest:
Cross-KDE support for file metadata indexing via nepomuk and soprano.
If you don't want to couple the message to those particular packages,
then maybe just reference the NEPOMUK project instead.
(Also, I note in passing the existing kde-base/pykde4 use.local.desc has
a tyop of Nemomuk.)
--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo $...@${b}
pgpiWIEaslsSS.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ryan Hill wrote: Richard Freeman wrote: I'm actually hard pressed to think of any unix-based software that uses the filename to store a mandatory file format versioning specifier of some kind. $ ls /usr/lib I was referring to a file FORMAT versioning scheme - not a file CONTENT versioning scheme. The formats of all the files in /usr/lib are generally identical. Where they vary it has nothing to do with their filenames. The reason for the version in the filenames is that the content is versioned. The dynamic linker doesn't need to consult the filename to figure out how to parse a shared object. It only consults the filename to figure out which shared object is needed. That is actually analogous to putting the package name/version in the ebuild filename. In any case, I'm not trying to say that these issues absolutely prevent the adoption of GLEP 55. It just leaves a sour taste in my mouth, and keeps nagging at me that there must be a better way. I'd rather see the number of filename variations be kept to a minimum. Sure, if we were talking about a one-time change from ebuild to ebuild2 and in five years a change to ebuild3 then that would be one thing. It seems like we could be up to ebuild-kde4-3.2 in six months. And I don't mean to suggest that I don't think that efforts would be made to keep things sensible. It just seems like once we start down that road it will be hard to turn around if we don't like where we end up.
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 18:47:07 -0500 Richard Freeman ri...@gentoo.org wrote: It seems like we could be up to ebuild-kde4-3.2 in six months. Why on earth do people think that? Of all the crazy being thrown around, this is the only one wearing a tutu. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: On Mon, 23 Feb 2009 18:47:07 -0500 Richard Freeman ri...@gentoo.org wrote: It seems like we could be up to ebuild-kde4-3.2 in six months. Why on earth do people think that? Of all the crazy being thrown around, this is the only one wearing a tutu. I suppose I'm exaggerating a little deliberately to make a point. It isn't so much that I don't think that people designing the extensions won't use sense, but that we're still potentially facing multiple new file extensions per year. Maybe not 15, but certainly 1-3. That can add up fast. If we had been doing this all along then we'd probably expect there to be upwards of 10-20 file extensions in portage today. It just seems like it isn't the best solution. You can get the same effect by just sticking something in a comment line a few lines into the ebuild in a fixed position. Sure, the file might need to be read twice, but unless the reading takes place widely separated in time the file is going to be in the cache the second time around. With proper caching you only need to scan files that have changed - we can't have that many daily commits, can we? I'll probably refrain from commenting further - I trust the council to weigh all the options and go with whatever makes the most sense. However, I did want to make it clear that I don't think that the folks advocating this approach are out to release 47 EAPI releases per year or anything...
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, 23 Feb 2009 19:17:19 -0500 Richard Freeman ri...@gentoo.org wrote: It just seems like it isn't the best solution. You can get the same effect by just sticking something in a comment line a few lines into the ebuild in a fixed position. No you can't. It doesn't work with existing package managers, and it doesn't let you change name or version rules. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Alistair Bush ali_b...@gentoo.org wrote: Tiziano Müller wrote: Instead of switching file extension every time the eapi is changed you could also increment it only when a new EAPI breaks sourcing the ebuild compared to the requirements of the prior EAPI. (This way you'd in fact split EAPI into a major- and a minor-version.) Doesn't that just add extra complexity for no gain. Actually, I think there would be a huge gain. The gain would be that suddenly all those who oppose glep-55 because they're afraid the filename suffix will change too often will suddenly have nothing to worry about. For those who think glep-55 is the right thing to do, it really *is* glep-55, but with a small caveat that we shouldn't just change the filename extension for every single little feature enhancement. -- Jim Ramsay Gentoo/Linux Developer (rox,gkrellm,fluxbox,vim)
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote:
On Mon, 23 Feb 2009 19:17:19 -0500
Richard Freeman ri...@gentoo.org wrote:
It just seems like it isn't the best solution. You can get the same
effect by just sticking something in a comment line a few lines into
the ebuild in a fixed position.
No you can't. It doesn't work with existing package managers,
Agreed. This would require some delay in implementation and would
require users to have some minimal package manager version to handle
major changes in a repository.
and it
doesn't let you change name or version rules.
Neither does putting the EAPI in the filename as far as I can tell. It
isn't like you want to have ebuild filenames like:
foo-1.1.ebuild-\{EAPI\=1\ \;\ if\ \[\[\ \$PV\ =\ 2.6\ \]\]\ \;\ then\
EAPI\=2\ \;\ fi\}
Putting the EAPI in the filename forces it to be a rigid constant for
the purposes of determining how to parse the file. Putting the EAPI in
a comment line does the same. Both allow for dynamic manipulation of
the variable at a later stage of parsing, but this is after the package
manager has committed to sourcing the file in some particular manner.
If anything you get more flexibility putting it inside the file since at
least you can make it very long without clogging up command lines.
Re: [gentoo-dev] [RFC] global useflags
On Tue, Feb 24, 2009 at 4:52 AM, Josh Sled js...@asynchronous.org wrote: (Also, I note in passing the existing kde-base/pykde4 use.local.desc has a tyop of Nemomuk.) Oh, sweet irony :) -- ~Nirbheek Chauhan
Re: [gentoo-dev] [RFC] global useflags
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josh Sled wrote: Markus Meier mae...@gentoo.org writes: semantic-desktop: Semantic desktop allows for storage of digital information and its metadata to allow the user to express his personal mental models, making all in formation become intuitively accessible I find this description pretty content-free and hand-wavy. I usually care to know what the concrete effect of a use flag is, to know if it's something I want to enable, in terms of features provided and the dependencies implied. To that end, please allow me to suggest: Cross-KDE support for file metadata indexing via nepomuk and soprano. If you don't want to couple the message to those particular packages, then maybe just reference the NEPOMUK project instead. (Also, I note in passing the existing kde-base/pykde4 use.local.desc has a tyop of Nemomuk.) Fixed. Thanks for the heads up. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmjafAACgkQcAWygvVEyAIgSQCfRXEBkfwJvFxkC0ReDPux2rr1 LmsAoJ9SrNE0pws6FsNxv1wrLcMeiUF7 =i+3r -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] global useflags
On Tuesday 24 of February 2009 00:22:39 Josh Sled wrote: To that end, please allow me to suggest: Cross-KDE support for file metadata indexing via nepomuk and soprano. If you don't want to couple the message to those particular packages, then maybe just reference the NEPOMUK project instead. Then maybe: Cross-KDE support for semantic search and information retrieval. As for particular packages, there are more of them (strigi is quite important for example), so maybe it's better to not specify any of them as suggested. (Also, I note in passing the existing kde-base/pykde4 use.local.desc has a tyop of Nemomuk.) Good catch, source of this issue was in metadata.xml in overlay. -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] bash-4.0 regression heads up (escaped semicolons in subshells)
On Sunday 22 February 2009 18:03:23 Dawid Węgliński wrote:
On Sunday 22 of February 2009 23:39:11 Mike Frysinger wrote:
On Sunday 22 February 2009 17:30:09 Dawid Węgliński wrote:
On Sunday 22 of February 2009 00:27:10 Mike Frysinger wrote:
looks like bash-4.0 has broken semicolon escaping in subshells. this
comes up when using find's -exec like we do in a few places in
eclasses: ls=$(find $1 -name '*.po' -exec basename {} .po \;);
shift you can work around the issue in a couple of ways:
- quote the semicolon:
';')
- use backticks
`find \;`
i'll tweak the eclasses to use quoting for now
FYI. Not only find's semicolons are affected. It also happens in case
;; construction.
embedded case statements in $(...) subshells have always been broken.
bash-4.0 is supposed to fix that. if you have some code that is broken,
please post it so i can push it upstream.
It wasn't me who experienced that, but a user:
13:50 diabel- dir /usr/share/doc/wxGTK-2.8.9.1-r3
13:50 diabel-
/var/tmp/binpkgs/x11-libs/wxGTK-2.8.9.1-r3/temp/environment: line 2989:
błąd składni przy nieoczekiwanym znaczniku `;;'
13:50 diabel-
/var/tmp/binpkgs/x11-libs/wxGTK-2.8.9.1-r3/temp/environment: line 2989: `
;;' * * ERROR: x11-libs/wxGTK-2.8.9.1-r3 failed.
All it states is syntax error near double semicolons.
this is probably the same issue i pointed out originally. re-emerge bash and
it should work.
-mike
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] http://bugs.gentoo.org/show_bug.cgi?id=232084
I was looking to do a workaround on a per compiler basis.
I'm looking at toolchain-funcs.eclass, and specifically
${gcc-fullversion}. I've got a broken ebuild (dhcdbd) which requires
-U_FORTIFY_SOURCE to compile correctly with GCC 4.3.3. But reading
tells me that I should not use this eclass to set compiler settings
directly. Will this work, and other than the merit of the fix is there
a more desirable structure for such a solution?
inherit flag-o-matic toolchain-funcs
if [ ${gcc-fullversion} -eq 4.3.3 ] #(or whatever the 4.3.3
$gcc-fullversion} outputs)
then
append-flags -U_FORTIFY_SOURCE
fi
Thanks for the help.
Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Luca Barbato wrote:
Ciaran McCreesh wrote:
Because your proposal addresses none of the underlying problems which
GLEP 55 was created to solve.
let's get some numbers to have an idea of the dimension of the problem.
domino portage # wc -l /dev/shm/eapi_files.list
2854 /dev/shm/eapi_files.list
domino portage # ls *-*/*/*.ebuild | wc -l
25761
domino portage # grep -l EAPI eclass/*.eclass | wc -l
22
domino portage # ls eclass/*.eclass | wc -l
240
there aren't eclasses setting EAPI directly.
eapi is set either using EAPI=X or EAPI=X
domino portage # time grep EAPI *-*/*/*.ebuild /dev/shm/eapi_files.list
real0m1.019s
user0m0.608s
sys 0m0.412s
domino portage # time (for a in *-*/*/*.ebuild*; do echo ${A##*.ebuild};
done) /dev/null
real0m0.916s
user0m0.764s
sys 0m0.152s
domino portage # time emerge --regen /dev/shm/regen
real0m9.308s
user0m7.648s
sys 0m1.664s
Restricting eapi so it could surely parsed using something as
complex as grep would and using a two stage parsing would increase to
about 1/9
Using a dumb way to extract the eapi from extension seems to take 1/10
Is there any technical merit in putting eapi in the file extension while
we could restrict the format the same way in file and have about the
same, negligible, performance hit? (I used warm cache since you need the
file anyway so you don't spend time to look it up twice or put it in
cache twice)
Please come up with other numbers or saner implementations to compare.
lu
--
Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] http://bugs.gentoo.org/show_bug.cgi?id=232084
On Tuesday 24 February 2009 00:57:25 Andrew D Kirch wrote:
I was looking to do a workaround on a per compiler basis.
I'm looking at toolchain-funcs.eclass, and specifically
${gcc-fullversion}. I've got a broken ebuild (dhcdbd) which requires
-U_FORTIFY_SOURCE to compile correctly with GCC 4.3.3.
it's broken whenever fortify source is used, but gcc-4.3.3 is more of an issue
because it's on by default. however, this flag should not go in any dhcdbd
ebuild considering the fix posted by Magnus to that bug is clearly correct.
But reading
tells me that I should not use this eclass to set compiler settings
directly. Will this work, and other than the merit of the fix is there
a more desirable structure for such a solution?
inherit flag-o-matic toolchain-funcs
if [ ${gcc-fullversion} -eq 4.3.3 ] #(or whatever the 4.3.3
$gcc-fullversion} outputs)
then
append-flags -U_FORTIFY_SOURCE
fi
i'll just address style/usage issues here rather than is this change even
correct ...
-eq is for numeric values, not strings. so you'd want:
[[ $(gcc-fullversion) == 4.3.3 ]] append-cppflags -U_FORTIFY_SOURCE
-mike
signature.asc
Description: This is a digitally signed message part.
