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
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
-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.
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
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?
-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
-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
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
-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
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.
-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
-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
-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
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,
-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
-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).
-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
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
-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
-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
-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
-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
-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
-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
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
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
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
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
-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.
-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
-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
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
-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.
-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,
-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
35 matches
Mail list logo
