Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On Fri, 01 Aug 2008 19:02:48 -0700 Zac Medico [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, It might good to add support for a new RESTRICT=live value in ebuilds. By specifying this value, an ebuild would be able to indicate that it uses src_unpack() to download sources from some type of live repository such as cvs, darcs, git, mercurial, or svn. If we go with the RESTRICT solution, I'd rather use RESTRICT=versioned to indicate that a) ebuild version doesn't reflect upstream version (in most cases) b) upstream changes don't result in a new version Marius
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
Sorry that this is slightly OT, but maybe one should think about this point in this discussion: It seems like USE would be an unconventional location to store that information and I'm not sure that it really belongs in the ebuild. USE=live could perfectly make sense, if it is equipped with the obvious meaning: I suggest that if it is set, then it is attempted before building to download the newest source from cvs/svn/git/monotone/bzr/..., otherwise only the previously downloaded source is recompiled. Currently, this functionality, which is extremely useful for systems without permanent internet connection, is only implemented inconsistently by using environment variables, differently for each vcs: cvs: CVS_OFFLINE or CVS_OFFLINE_package_name git: EGIT_OFFLINE or ESCM_OFFLINE svn: ESVN_OFFLINE or ESCM_OFFLINE ???: Perhaps not implemented at all? Then it would also make sense that @live-ebuilds consists only of those packages for which the live USE-flag is actually set (because the user does not want to treat them as live).
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vaeth wrote: Sorry that this is slightly OT, but maybe one should think about this point in this discussion: It seems like USE would be an unconventional location to store that information and I'm not sure that it really belongs in the ebuild. USE=live could perfectly make sense, if it is equipped with the obvious meaning: I suggest that if it is set, then it is attempted before building to download the newest source from cvs/svn/git/monotone/bzr/..., otherwise only the previously downloaded source is recompiled. Currently, this functionality, which is extremely useful for systems without permanent internet connection, is only implemented inconsistently by using environment variables, differently for each vcs: cvs: CVS_OFFLINE or CVS_OFFLINE_package_name git: EGIT_OFFLINE or ESCM_OFFLINE svn: ESVN_OFFLINE or ESCM_OFFLINE ???: Perhaps not implemented at all? Then it would also make sense that @live-ebuilds consists only of those packages for which the live USE-flag is actually set (because the user does not want to treat them as live). Well, it seems to me that you're trying to shoehorn a USE flag into a role that's intended to be filled by package sets. The idea is that instead of settings USE flags in package.use, you'd define a package set containing the specific packages that you want rebuilt. Trying to define your set inside package.use would be an abuse of package.use and we've already got package sets designed for that purpose. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiVumgACgkQ/ejvha5XGaMhRACeNiJD30ggs/plNGuhX78B63Yv fX4An2faHig4ZreJD/3I1uGOEa/UTaDb =p9G+ -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
Vaeth wrote: The main point in introducing the live USE flag should be IMHO to let the user decide whether the sources should be fetched. The fact that IUSE then marks live ebuilds in the way which you wanted is an additional side effect. A tend to agree with Zac that USE flags should not dictate package manager behavior (e.g. whether a package gets included in a specific package set or defining a package as live), and the idea of the IUSE side-effect seems a bit unclean (i.e., behaviors that the dev did not intend might end up being a surprize; I think we need to be careful about side-effects). However, I do see the point about the RESTRICT variable. Throwing random flags into it does not seem ideal, and I think convenience should take a back seat to correctness when designing, e.g., ebuild syntax/rules. But why would using a new variable require an EAPI change any more than adding new flags to RESTRICT? I.e., if people start using OPTIONS= or FLAGS=, it would simply be ignored by older package manager versions, just like new RESTRICT values would be ignored. Or am I missing something fundamental? -Joe
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On Sun, Aug 3, 2008 at 12:25 AM, Zac Medico [EMAIL PROTECTED] wrote: Santiago M. Mola wrote: I don't think we're in a hurry for this feature, so I don't see the need of using suboptimal hacks in order to avoid an EAPI bump. Furthermore, EAPI 2 is supposed to be done in the near future, right? Regards, I don't view the RESTRICT=live idea as suboptimal or a hack in any way. I see it as a legitimate use of an existing ebuild variable that's already used for lots of other legitimate purposes. Let me rephrase the point as that this method should not be favoured over others just because it doesn't require an EAPI bump. Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Peterson wrote: However, I do see the point about the RESTRICT variable. Throwing random flags into it does not seem ideal, and I think convenience should take a back seat to correctness when designing, e.g., ebuild syntax/rules. But why would using a new variable require an EAPI change any more than adding new flags to RESTRICT? I.e., if people start using OPTIONS= or FLAGS=, it would simply be ignored by older package manager versions, just like new RESTRICT values would be ignored. Or am I missing something fundamental? What you're missing is that only a specific subset of variables is cached in /usr/portage/metadata/cache. Now that you mention it, we could introduce a new variable called EBUILD_FLAGS and start caching it in new versions of portage. It wouldn't necessarily require an EAPI bump as long as it can safely be ignored by older versions of portage. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiWD04ACgkQ/ejvha5XGaO8JgCgv3dIDZtq/7qnmCadq7cpfUQs CNUAn334taZBgjWwM9UAxW97mEO9WCE6 =vbtT -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: Joe Peterson wrote: However, I do see the point about the RESTRICT variable. Throwing random flags into it does not seem ideal, and I think convenience should take a back seat to correctness when designing, e.g., ebuild syntax/rules. But why would using a new variable require an EAPI change any more than adding new flags to RESTRICT? I.e., if people start using OPTIONS= or FLAGS=, it would simply be ignored by older package manager versions, just like new RESTRICT values would be ignored. Or am I missing something fundamental? What you're missing is that only a specific subset of variables is cached in /usr/portage/metadata/cache. Now that you mention it, we could introduce a new variable called EBUILD_FLAGS and start caching it in new versions of portage. It wouldn't necessarily require an EAPI bump as long as it can safely be ignored by older versions of portage. Zac Oh and by the way, I should mention that it might not be worth it to add a whole new variable. I think RESTRICT=live-sources is a perfectly fine, especially considering the the existing RESTRICT=primaryuri value is similar in some ways, including perceived polarity. If we do decide to add a new variable then perhaps we should move primaryuri to the new variable as well, for consistency. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiWGY0ACgkQ/ejvha5XGaPGlQCgiDvulaAgLqdHXyoFVPPXdF6t 22gAnAiUNyY4fbmCl2WeapH3n7g1Y/8A =l90F -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
Zac Medico wrote: What you're missing is that only a specific subset of variables is cached in /usr/portage/metadata/cache. Now that you mention it, we could introduce a new variable called EBUILD_FLAGS and start caching it in new versions of portage. It wouldn't necessarily require an EAPI bump as long as it can safely be ignored by older versions of portage. Yes, that was my thinking. Oh and by the way, I should mention that it might not be worth it to add a whole new variable. I think RESTRICT=live-sources is a perfectly fine, especially considering the the existing RESTRICT=primaryuri value is similar in some ways, including perceived polarity. If we do decide to add a new variable then perhaps we should move primaryuri to the new variable as well, for consistency. Yes, that's sort of what I am thinking. Migrate options that really do not belong in RESTRICT to another variable (and keep them in RESTRICT, of course, for backward compat for now). Then introduce new ones into whichever variable makes sense. I'm not sure the EBUILD_ in EBUILD_FLAGS would be necessary (redundant?). Maybe even OPTIONS or PROPERTIES makes more sense. In fact, FLAGS might be a little too generic, even? Worth a short discussion. -Joe
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Peterson wrote: Yes, that's sort of what I am thinking. Migrate options that really do not belong in RESTRICT to another variable (and keep them in RESTRICT, of course, for backward compat for now). Then introduce new ones into whichever variable makes sense. Personally I think people are far too concerned about the name of the variable. I only see a what I consider to be a trivial or negligible benefit in separating these things into two different variables. However, it it makes more people happy then I guess I'm for it. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiWKJMACgkQ/ejvha5XGaOtxwCdHWWJ9sFaVsSiQF36j1WDmJOY Vf8AmgP9MlJGdQC5jzgGkjdUqmv+Y+F8 =WWt3 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
Zac Medico wrote: Personally I think people are far too concerned about the name of the variable. I only see a what I consider to be a trivial or negligible benefit in separating these things into two different variables. However, it it makes more people happy then I guess I'm for it. Different people have differing sensitivity to things like this (aesthetics, consistency, etc.). IMHO, this particular one is not a *huge* deal (picking my battles, I personally would not choose to be too vehement on this one), but it's always nice to pick the most elegant/logical way to do things, especially for things that are exposed to the dev/ebuild interface and are hard to change later. -Joe
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Peterson wrote: I'm not sure the EBUILD_ in EBUILD_FLAGS would be necessary (redundant?). Maybe even OPTIONS or PROPERTIES makes more sense. In fact, FLAGS might be a little too generic, even? Worth a short discussion. One potential issue with using a short generic name is the potential for variable name collisions. It's mainly an issue if we want to mark the variable readonly during normal ebuild phases. If the variable is marked readonly then bash will not allow that variable name to be used as either a global or a _local_ variable. Maybe it doesn't really matter though. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiWKuYACgkQ/ejvha5XGaPdgQCfXyDdAPN22+Jn/szjD0zG99eH xqgAn28jCCmEOLoKfKSspbJbGskUwjtI =rDmY -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Peterson wrote: I'm not sure the EBUILD_ in EBUILD_FLAGS would be necessary (redundant?). Maybe even OPTIONS or PROPERTIES makes more sense. In fact, FLAGS might be a little too generic, even? Worth a short discussion. I think something like PROPERTIES or ATTRIBUTES would be nice. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiWNvgACgkQ/ejvha5XGaML/QCgj7Aof1UEVGrtBNcloDjFMhDJ izEAn2FTGTnnDa23XEF3ZENc9UaQU0P4 =JrMC -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It seems, Slightly like an abuse of the RESTRICT variable. I had thought that RESTRICT was generally for when a normal ebuild needed a feature turning off (such as mirroring, strict checking and hopefully one day ccache). 5:) Overloading it with the live value doesn't seem to fit into that scheme... If there's need for a new class of ebuild information (such as a new way of categorizing ebuilds by feature), perhaps we should add an ebuild features variable specifically for the purpose? Are there many ebuilds where differentiating by inheritance is inaccurate? If so, I'd definitely suggest a new variable, if not then perhaps it's not worth the effort for the accuracy (there are eclasses for almost every type of live ebuild). If adding a new variable would require an EAPI bump (rather than simply being ignored by older versions of portage) then I'd still suggest against overloading a variable from its normal usage, especially if something better's already in the works. If we start adding bits and pieces against the naming convention for ease now, it has the potential to end up being ugly (and a problem that needs fixing) later down the line... Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiUJIUACgkQu7rWomwgFXobdwCeJyvzTtdPLAC0AoqFM8O69ajl wwQAoLiFutlJw/LjHltw2uEAkCdPHNGU =gUMq -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
2008-08-02 04:02:48 Zac Medico napisał(a): Hi everyone, It might good to add support for a new RESTRICT=live value in ebuilds. By specifying this value, an ebuild would be able to indicate that it uses src_unpack() to download sources from some type of live repository such as cvs, darcs, git, mercurial, or svn. This new RESTRICT=live value would be useful in at least a couple of ways. One is that it could be used to implement a @live-rebuild package set that's based on RESTRICT instead of INHERITED [1]. It could also be used to implement a more accurate LIVEVCS.stable check in repoman, again based on RESTRICT instead of INHERITED [2]. We already have plans for more advanced live ebuild support, including live update detection, that will involve an EAPI bump [3]. However, the RESTRICT=live value is a simple enhancement that we can add now, without the need for an EAPI bump. Thoughts? The names of other RESTRICT values are related to features which are restricted. The new proposed value is intended for live ebuilds so its name should be negation of this feature. I think that something like RESTRICT=constant-sources would be better. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arfrever Frehtes Taifersar Arahesis wrote: 2008-08-02 04:02:48 Zac Medico napisał(a): The names of other RESTRICT values are related to features which are restricted. The new proposed value is intended for live ebuilds so its name should be negation of this feature. I think that something like RESTRICT=constant-sources would be better. Honestly I don't care about whatever the convention is but if people prefer some other name then that fine with me because the name really makes no difference to me. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiUMwEACgkQ/ejvha5XGaPMJQCfR9L0OWipq1Mi3n8SrcOG5SdI ZekAoLV/JMLaA7Om2RbxfhTIgdX0nqmi =I0P1 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Auty wrote: It seems, Slightly like an abuse of the RESTRICT variable. I had thought that RESTRICT was generally for when a normal ebuild needed a feature turning off (such as mirroring, strict checking and hopefully one day ccache). 5:) Overloading it with the live value doesn't seem to fit into that scheme... Honestly I don't care what the existing scheme is. I just see the RESTRICT list as a set of boolean flags that give me more information about the ebuild than I'd have without it. Here's what we've got now: binchecks - Disable all QA checks for binaries. bindist - Distribution of binary packages is restricted. fetch - Files will not be fetched via SRC_URI. installsources - Disable FEATURES=installsources. mirror - Disable mirroring. primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS. strip - Final binaries/libraries will not be stripped. test - Do not run src_test even if user has FEATURES=test. userpriv - Disables FEATURES=userpriv. Looking at the above list I say it's fair game to put just about any boolean flag in RESTRICT. If there's need for a new class of ebuild information (such as a new way of categorizing ebuilds by feature), perhaps we should add an ebuild features variable specifically for the purpose? That requires an EAPI bump, which also means that it can't be used in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we can use it right now in any ebuild. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiUNkEACgkQ/ejvha5XGaM9zACeIOK+J84QpqtFLU3jkjFUM5qv KzcAnihwK3ugnnVAmLMcnDwG/9gld14U =Eqiy -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: | Honestly I don't care what the existing scheme is. Fair enough, I don't maintain the code or have to deal with the complaints. It seems a waste to abandon an existing scheme though. Particularly since RESTRICT is an odd name for random boolean flags. Something like OPTIONS would be better, but it that can't be added/changed quickly. Is there an urgent pressing need for this? | primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS. | Looking at the above list I say it's fair game to put just about any | boolean flag in RESTRICT. To me, almost every item in that list has not, disable, restrict or some other negative in it, which lets it fit into a restriction. Primaryuri is the only one that looks out of place. You did sound up for a name change though, and if nothing else please do change it. Our new users/developers that don't know RESTRICT is seen as a general purpose options flag will not find it intuitive and will definitely wonder what RESTRICT=live means. Not everybody knows the ebuild format intimately, and allowing people to easily pick up what's going on is important... | That requires an EAPI bump, which also means that it can't be used | in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we | can use it right now in any ebuild. It is simpler, and as I say if there's an urgent need then go for it, but to me it feels like it's bolting on functionality into any space it'll go. Given that some time was spent changing all the noblah flags to blah to fit the RESTRICT name, it's a little disappointing to consider shoving extra flags in it now it all makes sense. This is a relatively minor point. In the long run, if people don't like it, it'll get QA bugged/ironed out, if they do it'll stay, you just asked for thoughts... 5:) Mike 5:) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiUT5cACgkQu7rWomwgFXqqdACfadwat4gS8/O4mX1zwcI+0VeU XawAnjbJa2LXHiK1VMN7ZBf9ICNK+dtl =572l -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On Sat, Aug 2, 2008 at 12:26 PM, Zac Medico [EMAIL PROTECTED] wrote: Mike Auty wrote: If there's need for a new class of ebuild information (such as a new way of categorizing ebuilds by feature), perhaps we should add an ebuild features variable specifically for the purpose? That requires an EAPI bump, which also means that it can't be used in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we can use it right now in any ebuild. I don't think we're in a hurry for this feature, so I don't see the need of using suboptimal hacks in order to avoid an EAPI bump. Furthermore, EAPI 2 is supposed to be done in the near future, right? Regards, -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED]
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Santiago M. Mola wrote: On Sat, Aug 2, 2008 at 12:26 PM, Zac Medico [EMAIL PROTECTED] wrote: Mike Auty wrote: If there's need for a new class of ebuild information (such as a new way of categorizing ebuilds by feature), perhaps we should add an ebuild features variable specifically for the purpose? That requires an EAPI bump, which also means that it can't be used in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we can use it right now in any ebuild. I don't think we're in a hurry for this feature, so I don't see the need of using suboptimal hacks in order to avoid an EAPI bump. Furthermore, EAPI 2 is supposed to be done in the near future, right? Regards, I don't view the RESTRICT=live idea as suboptimal or a hack in any way. I see it as a legitimate use of an existing ebuild variable that's already used for lots of other legitimate purposes. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiU3toACgkQ/ejvha5XGaOqJQCgp0VTgcLgsyqvTMOl4yAEv+M9 Al8AoJlwWW3y3CIy4nlTfvY+QnouVFuQ =XMyh -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Auty wrote: Zac Medico wrote: | Honestly I don't care what the existing scheme is. Fair enough, I don't maintain the code or have to deal with the complaints. It seems a waste to abandon an existing scheme though. The scheme is pretty worthless in my eyes. The RESTRICT variable is quite useful for general purpose boolean flags so I see no reason not to use it as such. Particularly since RESTRICT is an odd name for random boolean flags. Something like OPTIONS would be better, but it that can't be added/changed quickly. Is there an urgent pressing need for this? | primaryuri - Fetch from URLs in SRC_URI before GENTOO_MIRRORS. | Looking at the above list I say it's fair game to put just about any | boolean flag in RESTRICT. To me, almost every item in that list has not, disable, restrict or some other negative in it, which lets it fit into a restriction. Primaryuri is the only one that looks out of place. Again, such schemes are pretty worthless to me. But then, to have a RESTRICT=live setting for ebuilds would be quite useful. You did sound up for a name change though, and if nothing else please do change it. Our new users/developers that don't know RESTRICT is seen as a general purpose options flag will not find it intuitive and will definitely wonder what RESTRICT=live means. Not everybody knows the ebuild format intimately, and allowing people to easily pick up what's going on is important... I chose live because I think it's easy for people to associate it with live ebuilds, which I believe is a common term used to refer to ebuild that download live sources in src_unpack. What's in a name though? I'll gladly use whatever name satisfies the most people. | That requires an EAPI bump, which also means that it can't be used | in ebuilds with EAPI 0 or 1. The RESTRICT solution is simpler and we | can use it right now in any ebuild. It is simpler, and as I say if there's an urgent need then go for it, but to me it feels like it's bolting on functionality into any space it'll go. Given that some time was spent changing all the noblah flags to blah to fit the RESTRICT name, it's a little disappointing to consider shoving extra flags in it now it all makes sense. Well, RESTRICT=live makes perfect sense to me and I see it as a legitimate use of an existing ebuild variable that's already used for lots of other legitimate purposes. This is a relatively minor point. In the long run, if people don't like it, it'll get QA bugged/ironed out, if they do it'll stay, you just asked for thoughts... 5:) Mike 5:) Thanks for you input. It just seems to me that you're putting some artificial limitations on the RESTRICT variable while I see it as a more generically useful tool to accomplish a variety of useful purposes. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiU4QEACgkQ/ejvha5XGaOwygCfSVU2FPS9Y83JD4X/nTu5BTW+ 6RIAoLsEUDuEQKNkC7B2aPKCokMyETHv =bxM5 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Arfrever Frehtes Taifersar Arahesis wrote: 2008-08-02 04:02:48 Zac Medico napisał(a): The names of other RESTRICT values are related to features which are restricted. The new proposed value is intended for live ebuilds so its name should be negation of this feature. I think that something like RESTRICT=constant-sources would be better. Like I've said before, that particular convention is pretty worthless in my eyes. I'd much prefer RESTRICT=live-sources if we want to use a longer name. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiU6I8ACgkQ/ejvha5XGaOGLgCfcSDPfcoxmOdgZZlG4j1ag10O LxoAoKlrcrCVMYPaGQCTKF0Qf5GcljBP =9nNG -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico schrieb: I chose live because I think it's easy for people to associate it with live ebuilds, which I believe is a common term used to refer to ebuild that download live sources in src_unpack. What's in a name though? I'll gladly use whatever name satisfies the most people. Why not rename live to something which makes more sense in the RESTRICT environment? Like the constant-source suggestion by Arfrever? Because for me 'RESTRICT=live' reads like: Live(-builds) are not possible with this ebuild. Pushing random boolean flags in a variable, just because it already happens to be there, seems (for me) to be the wrongest possible approach. This would be quite similar to: We want to store the ebuild's author in the ebuild... Hmm - we would need an additional string variable for this ... Come - let's use the IUSE variable - there are already strings in there (perhaps add an '@' before the author so we can parse it). Just my 2ct, René -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiU6LkACgkQ4UOg/zhYFuBrVgCfRs/69DxNBy3TN0fsLr20gURW BxMAnie5SoBzbKN6n2oMhOJvMywV1ydf =aOCm -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann wrote: Zac Medico schrieb: I chose live because I think it's easy for people to associate it with live ebuilds, which I believe is a common term used to refer to ebuild that download live sources in src_unpack. What's in a name though? I'll gladly use whatever name satisfies the most people. Why not rename live to something which makes more sense in the RESTRICT environment? Like the constant-source suggestion by Arfrever? Because for me 'RESTRICT=live' reads like: Live(-builds) are not possible with this ebuild. I'm pretty flexible on the name but like I said before I think the convention you're referring to is pretty worthless. Pushing random boolean flags in a variable, just because it already happens to be there, seems (for me) to be the wrongest possible approach. This would be quite similar to: We want to store the ebuild's author in the ebuild... Hmm - we would need an additional string variable for this ... Come - let's use the IUSE variable - there are already strings in there (perhaps add an '@' before the author so we can parse it). Just my 2ct, René Well, RESTRICT has long since evolved into a rather generic set of boolean flags and it's quite useful as such. I don't see any need for artificial limitations on what types of flags go there. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiU7l8ACgkQ/ejvha5XGaP0MwCfR/zaBv0afq019vOOjuaEzdAJ FhcAnRsedFGVQY9gyxJbadCqWEBLbfrZ =2gKy -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico schrieb: Well, RESTRICT has long since evolved into a rather generic set of boolean flags and it's quite useful as such. I don't see any need for artificial limitations on what types of flags go there. For you it is just one variable amongst others - and you really don't care about the relation between its name and its content. But perhaps just for the sake of easier understanding of ebuilds, this relation should be kept. Otherwise you'll read in future documentation: The name is just for historical reasons and does not reflect the content. -- And this is nearly always a stumbling block for the non-experienced. Perhaps in a later EAPI RESTRICT might be renamed to something like FLAGS - and then can really be used as a pool of flags. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiU8p8ACgkQ4UOg/zhYFuBeSQCfaPCuNXk99lde0lvriV1GFDMu 6FgAnRetvxI1uHWnZH2lizEiTIB+7IOC =wStZ -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
Zac Medico wrote: Arfrever Frehtes Taifersar Arahesis wrote: 2008-08-02 04:02:48 Zac Medico napisaB(a): The names of other RESTRICT values are related to features which are restricted. The new proposed value is intended for live ebuilds so its name should be negation of this feature. I think that something like RESTRICT=constant-sources would be better. Like I've said before, that particular convention is pretty worthless in my eyes. I'd much prefer RESTRICT=live-sources if we want to use a longer name. Looks fine to me. -- Luca Barbato Gentoo Council Member Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On Sun, Aug 3, 2008 at 4:36 AM, Zac Medico [EMAIL PROTECTED] wrote: Arfrever Frehtes Taifersar Arahesis wrote: 2008-08-02 04:02:48 Zac Medico napisał(a): The names of other RESTRICT values are related to features which are restricted. The new proposed value is intended for live ebuilds so its name should be negation of this feature. I think that something like RESTRICT=constant-sources would be better. Like I've said before, that particular convention is pretty worthless in my eyes. I'd much prefer RESTRICT=live-sources if we want to use a longer name. How about we just skip the reversed-boolean-usage/it's-a-long-name confusion/argument and just call it RESTRICT=tarballs ? I know not all distfiles are tarballs, but it gets the message across far better than constant-sources IMO :o) -- ~Nirbheek Chauhan
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On Fri, Aug 1, 2008 at 7:02 PM, Zac Medico [EMAIL PROTECTED] wrote: This new RESTRICT=live value would be useful in at least a couple of ways. One is that it could be used to implement a @live-rebuild package set that's based on RESTRICT instead of INHERITED [1]. It could also be used to implement a more accurate LIVEVCS.stable check in repoman, again based on RESTRICT instead of INHERITED [2]. We already have plans for more advanced live ebuild support, including live update detection, that will involve an EAPI bump [3]. However, the RESTRICT=live value is a simple enhancement that we can add now, without the need for an EAPI bump. Thoughts? For some of us in the peanut gallery it'd also be nice to document the pitfalls of grepping inherited to determine if it's a live ebuild (update-live-ebuilds has done it for years, fairly successfully..). Granted it's not clean, and yes, as a secondary check you may need to check for SVN_REPO_URI or else. This is also acting like people are going to follow this convention, which even in a perfect world means people will tend to forget this or not even know they're supposed to put it. -- avuton -- I've got a fever. And the only prescription is more cowbell. -- Christopher Walken
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On 2008/08/01, Zac Medico [EMAIL PROTECTED] wrote: It might good to add support for a new RESTRICT=live value in ebuilds. Since some people have a problem with this flag being put there, what about IUSE=live-rebuild as an alternative? It's use.desc would be something like add this package to the @live-rebuild set (only for Portage 2.2_rc6 and above). And the set implementation would be modified to only include packages for which this flag is enabled. -- TGL.
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 René 'Necoro' Neumann wrote: | Zac Medico schrieb: | Well, RESTRICT has long since evolved into a rather generic set of | boolean flags and it's quite useful as such. I don't see any need | for artificial limitations on what types of flags go there. | | For you it is just one variable amongst others - and you really don't | care about the relation between its name and its content. But perhaps | just for the sake of easier understanding of ebuilds, this relation | should be kept. Otherwise you'll read in future documentation: The name | is just for historical reasons and does not reflect the content. -- And | this is nearly always a stumbling block for the non-experienced. | | Perhaps in a later EAPI RESTRICT might be renamed to something like | FLAGS - and then can really be used as a pool of flags. Can the RESTRICT=live value be interpreted as , 'restrict this ebuild to live repositories' or , if you want, 'this package will only build from live repos'? In either case, I don't see the fuss regarding this naming thing, considering RESTRICT is already being used for similar functionality. Regards, - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiU9e8ACgkQNir3WYj9aLpH0wCfS0t7t9md+kPmVZsppiekybe4 TNUAoIsGXS+wnGTpqZRNLpRTLwSGG7vk =xLIG -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas de Grenier de Latour wrote: On 2008/08/01, Zac Medico [EMAIL PROTECTED] wrote: It might good to add support for a new RESTRICT=live value in ebuilds. Since some people have a problem with this flag being put there, what about IUSE=live-rebuild as an alternative? It's use.desc would be something like add this package to the @live-rebuild set (only for Portage 2.2_rc6 and above). And the set implementation would be modified to only include packages for which this flag is enabled. That's an interesting idea, however I think RESTRICT is a better fit for the attribute that we're trying to model. USE flags are something that can be enable or disabled but the user but the behavior of the src_unpack() method downloading live sources is not something that's generally controlled by a USE flag afaik. Are there any existing ebuilds that allow src_unpack to be toggled in this way via a USE flag? Is this something that would be desireable? Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiVAtsACgkQ/ejvha5XGaNWLwCgvOkEutL+2IYGF5Nz0ncH1GL/ k/8An3lwrLOUKKFaTNMVaYBLd0OryI67 =6uSV -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Avuton Olrich wrote: On Fri, Aug 1, 2008 at 7:02 PM, Zac Medico [EMAIL PROTECTED] wrote: For some of us in the peanut gallery it'd also be nice to document the pitfalls of grepping inherited to determine if it's a live ebuild (update-live-ebuilds has done it for years, fairly successfully..). I'm told that some ebuilds that are not really live ebuilds still inherit the same eclasses that are used for live ebuilds. So, there is no direct correspondence between inheriting one of these eclasses and being a live ebuild. Granted it's not clean, and yes, as a secondary check you may need to check for SVN_REPO_URI or else. The SVN_REPO_URI variable wouldn't be very useful because it only applies to the svn eclass, and it's not among the special metadata variables that you'll find cached in /usr/portgage/metadata/cache. This is also acting like people are going to follow this convention, which even in a perfect world means people will tend to forget this or not even know they're supposed to put it. It's not that hard to do, and if it's initially overlooked by an ebuild maintainer than its not really a difficult thing to spot and fix. Much more elusive bugs do exist. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiVBVsACgkQ/ejvha5XGaOUeACeJrXwikBgoEOVmBG6iaPqetTY 4qAAoKZ/CqcUwLaM/GU/XfDV7dKTwV9s =wM+N -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
On 2008/08/02, Zac Medico [EMAIL PROTECTED] wrote: USE flags are something that can be enable or disabled Here, what the flag would enable/disable is belonging of live packages to the @live-rebuild set. Compared to the RESTRICT solution, user gains an easy per-package control of this set (sure, the flag would be turned on in profiles, so that @live-rebuild is complete by default). but the behavior of the src_unpack() method downloading live sources is not something that's generally controlled by a USE flag afaik. Right, this live-rebuild USE flag would not control anything in the way the ebuild is executed, but only in the way the package is handled by Portage. It's not primary usage of USE flags, sure, but it's not completly unusual neither (for instance, take USE flags which are just there to trigger some convenience PDEPEND). Anyway, to rephrase / summarize my idea: - IUSE=live-rebuild in the ebuild == triggers LIVEVCS.stable repoman check - IUSE=live-rebuild in the ebuild, and package is installed, and USE flag live-rebuild is enabled for this package == makes it belong to the @live-rebuild set -- TGL.
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas de Grenier de Latour wrote: On 2008/08/02, Zac Medico [EMAIL PROTECTED] wrote: USE flags are something that can be enable or disabled Here, what the flag would enable/disable is belonging of live packages to the @live-rebuild set. Compared to the RESTRICT solution, user gains an easy per-package control of this set (sure, the flag would be turned on in profiles, so that @live-rebuild is complete by default). but the behavior of the src_unpack() method downloading live sources is not something that's generally controlled by a USE flag afaik. Right, this live-rebuild USE flag would not control anything in the way the ebuild is executed, but only in the way the package is handled by Portage. It's not primary usage of USE flags, sure, but it's not completly unusual neither (for instance, take USE flags which are just there to trigger some convenience PDEPEND). Anyway, to rephrase / summarize my idea: - IUSE=live-rebuild in the ebuild == triggers LIVEVCS.stable repoman check - IUSE=live-rebuild in the ebuild, and package is installed, and USE flag live-rebuild is enabled for this package == makes it belong to the @live-rebuild set It seems like USE would be an unconventional location to store that information and I'm not sure that it really belongs in the ebuild. Shoehorning it into package.use might have some benefits but USE flags are conventionally used to control ebuild behavior rather than package manager behavior. Perhaps some separate user config file would be more appropriate for that purpose. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiVHLoACgkQ/ejvha5XGaOq4QCeMZOJcHKn2d2LzhIeRmGrLjlu 2J8An1C1lpC5VsCPqnwz4kpPBVEFFRDE =M6Pf -END PGP SIGNATURE-
[gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, It might good to add support for a new RESTRICT=live value in ebuilds. By specifying this value, an ebuild would be able to indicate that it uses src_unpack() to download sources from some type of live repository such as cvs, darcs, git, mercurial, or svn. This new RESTRICT=live value would be useful in at least a couple of ways. One is that it could be used to implement a @live-rebuild package set that's based on RESTRICT instead of INHERITED [1]. It could also be used to implement a more accurate LIVEVCS.stable check in repoman, again based on RESTRICT instead of INHERITED [2]. We already have plans for more advanced live ebuild support, including live update detection, that will involve an EAPI bump [3]. However, the RESTRICT=live value is a simple enhancement that we can add now, without the need for an EAPI bump. Thoughts? Zac [1] http://planet.gentoo.org/developers/zmedico/2008/07/31/live_rebuild_package_set [2] http://sources.gentoo.org/viewcvs.py/portage?view=revrev=3457 [3] http://bugs.gentoo.org/show_bug.cgi?id=182028 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiTwEYACgkQ/ejvha5XGaO1yACbBdLxCzvVxMdW/IjeodgbktNJ /GYAniFIweB8+Gj/7XSlT2pEFD6/Ric9 =a+ak -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] New RESTRICT=live value for identification of live ebuilds?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: | Hi everyone, | | It might good to add support for a new RESTRICT=live value in | ebuilds. By specifying this value, an ebuild would be able to | indicate that it uses src_unpack() to download sources from some | type of live repository such as cvs, darcs, git, mercurial, or svn. | | This new RESTRICT=live value would be useful in at least a couple of | ways. One is that it could be used to implement a @live-rebuild | package set that's based on RESTRICT instead of INHERITED [1]. It | could also be used to implement a more accurate LIVEVCS.stable check | in repoman, again based on RESTRICT instead of INHERITED [2]. | | We already have plans for more advanced live ebuild support, | including live update detection, that will involve an EAPI bump [3]. | However, the RESTRICT=live value is a simple enhancement that we can | add now, without the need for an EAPI bump. Thoughts? | | Zac | | [1] | http://planet.gentoo.org/developers/zmedico/2008/07/31/live_rebuild_package_set | [2] http://sources.gentoo.org/viewcvs.py/portage?view=revrev=3457 | [3] http://bugs.gentoo.org/show_bug.cgi?id=182028 +1 - -- Luis F. Araujo araujo at gentoo.org Gentoo Linux -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiT6XwACgkQNir3WYj9aLrhlwCfdmyhqPLSSSgH68UvE7KopAkD siYAnjEANXpkbuTA83yRIsIztp9kDVL7 =dJiJ -END PGP SIGNATURE-
