[RFC] New RESTRICT=live value for identification of live ebuilds?

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[RFC] New RESTRICT=live value for identification of live ebuilds?

Zac Medico-2
-----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=rev&rev=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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Luis Francisco Araujo
-----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=rev&rev=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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Mike Auty-3
In reply to this post by Zac Medico-2
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Arfrever Frehtes Taifersar Arahesis-2
In reply to this post by Zac Medico-2
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 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Zac Medico-2
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Zac Medico-2
In reply to this post by Mike Auty-3
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Mike Auty-3
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Santiago M. Mola
In reply to this post by Zac Medico-2
On Sat, Aug 2, 2008 at 12:26 PM, Zac Medico <[hidden email]> 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: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Zac Medico-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Santiago M. Mola wrote:

> On Sat, Aug 2, 2008 at 12:26 PM, Zac Medico <[hidden email]> 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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Zac Medico-2
In reply to this post by Mike Auty-3
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Zac Medico-2
In reply to this post by Arfrever Frehtes Taifersar Arahesis-2
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

René Neumann
In reply to this post by Zac Medico-2
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Zac Medico-2
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

René Neumann
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Luca Barbato
In reply to this post by Zac Medico-2
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


Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Luis Francisco Araujo
In reply to this post by René Neumann
-----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-----

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Nirbheek Chauhan
In reply to this post by Zac Medico-2
On Sun, Aug 3, 2008 at 4:36 AM, Zac Medico <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Avuton Olrich
In reply to this post by Zac Medico-2
On Fri, Aug 1, 2008 at 7:02 PM, Zac Medico <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Thomas de Grenier de Latour-2
In reply to this post by Zac Medico-2
On 2008/08/01, Zac Medico <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] New RESTRICT=live value for identification of live ebuilds?

Zac Medico-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thomas de Grenier de Latour wrote:

> On 2008/08/01, Zac Medico <[hidden email]> 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-----

12