[gentoo-dev] [RFC] SRC_URI behaviour

[gentoo-dev] [RFC] SRC_URI behaviour

[Vadim A. Misbakh-Soloviov]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

Sometimes I find myself in a situation, when I need to use both
RESTRICT=fetch for the main distfile and allow fetch for additional ones
(langpacks, extensions and so on).
Sometimes it is even impossible to split that additions into separate
package, since they might want to replace some file (for example, Dear
Esther's translations).

So, in that case, I think,  it'd be useful to change SRC_URI behaviour a
bit:

for example:

SRC_URI="
	restrict://dearesther-linux-06082013-bin #fetch restrict
	linguas_ru? ( http://www.dear-esther.com/translations/DE_Russian.rar )
	linguas_hu? ( http://www.dear-esther.com/translations/DE_Hungarian.rar )
        linguas_hu2? (
http://www.dear-esther.com/translations/DE_Hungarian2.rar )
"
Alternatively it can be even:

SRC_URI="
	restrict+http://foo.bar/moo-123.run # mirror-restrict or specifying a
link for fetch-restrict (like for oracle-jdk)
"

And, moreover, I guess, SRC_URI can even be used for VCS:

SRC_URI="
	git+ssh://github.com/lol/moo.git
	hg+ssh://bitbucket.org/lol/moo
	svn+ssh://assembla.com/lol/moo
"

And it can also be extendable:

SRC_URI="
	hg+http://prosody.im/trunk
	modules? ( hg+https://prosody-modules.googlecode.com/hg )
"


Any thoughts?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov <mva@mva.name>wrote:

>
> And, moreover, I guess, SRC_URI can even be used for VCS:
>
> SRC_URI="
>         git+ssh://github.com/lol/moo.git
>         hg+ssh://bitbucket.org/lol/moo
>         svn+ssh://assembla.com/lol/moo
> "
>

Over my dead CVS access.


Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

[-- Attachment #2: Type: text/html, Size: 1127 bytes --]

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Rich Freeman]

On Sat, Jun 15, 2013 at 7:50 AM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
>
> On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov <mva@mva.name>
> wrote:
>>
>>
>> And, moreover, I guess, SRC_URI can even be used for VCS:
>>
>> SRC_URI="
>>         git+ssh://github.com/lol/moo.git
>>         hg+ssh://bitbucket.org/lol/moo
>>         svn+ssh://assembla.com/lol/moo
>> "
>
> Over my dead CVS access.

Grandstanding aside, it is probably best to take this in chunks.

The all-or-nothing fetch restriction control does seem like a good
place to start improving. I could certainly see where that could
create needless problems.  It just hasn't been much of an issue
because fetch restriction is rare.  Mirror restriction is likely a
bigger problem even if it is somewhat user-invisible.  Do we really
want to hammer something like dev.gentoo.org for patches that aren't
properly mirrored because the original source cannot be?

Rich

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 498 bytes --]

On Sat, Jun 15, 2013 at 1:12 PM, Rich Freeman <rich0@gentoo.org> wrote:

>
> Grandstanding aside, it is probably best to take this in chunks.


I just don't care to repeat for the Nth time the same reasoning for which I
don't want to mainstream VCS fetching.

It's just not going to happen as long as I got CVS access, it's not a
threat or a grandstanding, it's a simple boolean logic statement.

Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

[-- Attachment #2: Type: text/html, Size: 1037 bytes --]

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Vadim A. Misbakh-Soloviov]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

15.06.2013 18:50, Diego Elio Pettenò пишет:
> Over my dead CVS access.
Any reasonable/argumented objection?

And, anyway, quoted part is optional behaviour that should just make
ebuild-writing easy.
Mandatory part is to be able to have restrict://foo.bar and downloadable
things at the same time.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Alexander V Vershilov]

On 15 June 2013 15:50, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
>
> On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov <mva@mva.name>
> wrote:
>>
>>
>> And, moreover, I guess, SRC_URI can even be used for VCS:
>>
>> SRC_URI="
>>         git+ssh://github.com/lol/moo.git
>>         hg+ssh://bitbucket.org/lol/moo
>>         svn+ssh://assembla.com/lol/moo
>> "
>
>
> Over my dead CVS access.
>

Can you elaborate:
 do you object both proposals (about partial restrict and VCS-support)
or only second
one (VCS-support)?

It seems that there were no technical discussions about first one and
it seems quite
reasonable.

--
Alexander

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Diego Elio Pettenò]

On 15/06/2013 13:48, Alexander V Vershilov wrote:
> Can you elaborate:
>  do you object both proposals (about partial restrict and VCS-support)
> or only second
> one (VCS-support)?

As I already said in my answer to Rich, the VCS support is XOR'd with my
CVS access.

And I've already spent too much time on it again, so don't expect
further mail from me on the topic.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

Dnia 2013-06-15, o godz. 15:56:53
"Vadim A. Misbakh-Soloviov" <mva@mva.name> napisał(a):

> And, moreover, I guess, SRC_URI can even be used for VCS:
> 
> SRC_URI="
> 	git+ssh://github.com/lol/moo.git
> 	hg+ssh://bitbucket.org/lol/moo
> 	svn+ssh://assembla.com/lol/moo
> "

It simply can't work. Don't even try to implement, it's waste of time.
Just grep the tree, see how various packages use VCS-es. There's too
many differences, too many needs and -- most importantly -- VCS-es
change over time much more quickly than, say, unpackers.

Even *if* we get a SRC_URI VCS support that works for all consumers,
and that'd be awfully hard to do properly, it will eventually stop
being 'good enough' and require further changes. It will just become
never-ending story for a minor benefit.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Rich Freeman]

On Sat, Jun 15, 2013 at 8:14 AM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
> It's just not going to happen as long as I got CVS access, it's not a threat
> or a grandstanding, it's a simple boolean logic statement.

That IS grandstanding.  I'm not saying I disagree with the position
you advocate, but saying "do it my way or I'll quit" is basically
saying that reasoning besides the community has to add to the balance
of the choice their desire to have your contributions.

At work just about every boss I have had any respect for would have
fired me on the spot for making such a statement and not retracting it
(regardless of whether they ended up making the decision I was
advocating for).  They'd have been right to do so - the cost to an
organization of tolerating such behavior is higher than the benefits
any individual can offer.

It is possible to agree with your argument and fault your
communication style at the same time.

Rich

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Vadim A. Misbakh-Soloviov]

[-- Attachment #1: Type: text/plain, Size: 515 bytes --]

15.06.2013 20:05, Michał Górny пишет:
> It simply can't work. Don't even try to implement, it's waste of time.
As I already metioned to Diego — VCS part is just optional example of
that things, that can be useful.

Mainly idea in partial restricting.
And I suggest you all (including Diego) to discuss about that, instead
of oppositing vcs-related SRC_URI ;)

Actually, I've some more words to protect VCS links in SRC_URIs, but I'd
be quiet on that, untill discussion will go in right way ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Diego Elio Pettenò]

On 15/06/2013 14:06, Rich Freeman wrote:
> At work just about every boss I have had any respect for would have
> fired me on the spot for making such a statement and not retracting it

At work you're also paid to for the time you spend justifying for the
Nth time why a proposal is completely crazy and something that no sane
people would accept.

Nobody pays me to waste my time in explaining *again* why VCS ebuilds
should be a corner case and not something to spend time making easier to
create (because that's what it boils down to).

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 413 bytes --]

On 15/06/2013 14:11, Vadim A. Misbakh-Soloviov wrote:
> And I suggest you all (including Diego) to discuss about that, instead
> of oppositing vcs-related SRC_URI ;)

Then next time don't collapse two widely different proposals, especially
considering that one of the two has been already discussed to death.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 555 bytes --]

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 805 bytes --]

Am Samstag, 15. Juni 2013, 15:15:57 schrieb Diego Elio Pettenò:
> On 15/06/2013 14:06, Rich Freeman wrote:
> > At work just about every boss I have had any respect for would have
> > fired me on the spot for making such a statement and not retracting it
> 
> At work you're also paid to for the time you spend justifying for the
> Nth time why a proposal is completely crazy and something that no sane
> people would accept.
> 
> Nobody pays me to waste my time in explaining *again* why VCS ebuilds
> should be a corner case and not something to spend time making easier to
> create (because that's what it boils down to).

How about a blog link or a pointer to an old thread instead?

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Ulrich Mueller]

>>>>> On Sat, 15 Jun 2013, Rich Freeman wrote:

>> Over my dead CVS access.

> Grandstanding aside, it is probably best to take this in chunks.

> The all-or-nothing fetch restriction control does seem like a good
> place to start improving. I could certainly see where that could
> create needless problems. It just hasn't been much of an issue
> because fetch restriction is rare. Mirror restriction is likely a
> bigger problem even if it is somewhat user-invisible. Do we really
> want to hammer something like dev.gentoo.org for patches that aren't
> properly mirrored because the original source cannot be?

Trying to get this thread back on track: This part was already
proposed in bug 371413. I guess the main problem is to come up with a
good syntax for SRC_URI or RESTRICT.

"restrict+http:" (as suggested by the OP) is probably not enough
because it doesn't distinguish between fetch and mirror restriction.

Ulrich

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Diego Elio Pettenò]

On 15/06/2013 14:34, Ulrich Mueller wrote:
> "restrict+http:" (as suggested by the OP) is probably not enough
> because it doesn't distinguish between fetch and mirror restriction.

nofetch+http and nomirror+http ?

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Ulrich Mueller]

>>>>> On Sat, 15 Jun 2013, Diego Elio Pettenò wrote:

>> "restrict+http:" (as suggested by the OP) is probably not enough
>> because it doesn't distinguish between fetch and mirror
>> restriction.

> nofetch+http and nomirror+http ?

Or the other way around: {fetch,mirror}+http. I'd rather have RESTRICT
apply to all of SRC_URI (as it is now) and use the new syntax to
specify any exceptions from the restriction.

Ulrich

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Luca Barbato]

On 06/15/2013 02:34 PM, Vadim A. Misbakh-Soloviov wrote:
> 15.06.2013 18:50, Diego Elio Pettenò пишет:
>> Over my dead CVS access.
> Any reasonable/argumented objection?

to put in different words:

We do not want to use untraceable/transient/ephemeral sources for main
ebuilds, live ebuilds are corner cases. Ruby related stuff had it worst
regarding mis-packaging and total reliance on git with horrid stories
they might tell you later over a large coffee.

> And, anyway, quoted part is optional behaviour that should just make
> ebuild-writing easy.
> Mandatory part is to be able to have restrict://foo.bar and downloadable
> things at the same time.

In fact the restrict part got some proposals and not a terse and stern
reject.

lu

[gentoo-dev] Re: [RFC] SRC_URI behaviour

[Michael Palimaka]

On 15/06/2013 23:47, Ulrich Mueller wrote:
>>>>>> On Sat, 15 Jun 2013, Diego Elio Pettenò wrote:
>
>>> "restrict+http:" (as suggested by the OP) is probably not enough
>>> because it doesn't distinguish between fetch and mirror
>>> restriction.
>
>> nofetch+http and nomirror+http ?
>
> Or the other way around: {fetch,mirror}+http. I'd rather have RESTRICT
> apply to all of SRC_URI (as it is now) and use the new syntax to
> specify any exceptions from the restriction.
>
> Ulrich
>
>

I like this idea.

Best regards,
Michael

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Diego Elio Pettenò]

On 15/06/2013 14:47, Ulrich Mueller wrote:
> Or the other way around: {fetch,mirror}+http. I'd rather have RESTRICT
> apply to all of SRC_URI (as it is now) and use the new syntax to
> specify any exceptions from the restriction.
WFM

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Pacho Ramos]

El sáb, 15-06-2013 a las 12:50 +0100, Diego Elio Pettenò escribió:
> 
> On Sat, Jun 15, 2013 at 9:56 AM, Vadim A. Misbakh-Soloviov
> <mva@mva.name> wrote:
>         
>         And, moreover, I guess, SRC_URI can even be used for VCS:
>         
>         SRC_URI="
>                 git+ssh://github.com/lol/moo.git
>                 hg+ssh://bitbucket.org/lol/moo
>                 svn+ssh://assembla.com/lol/moo
>         "
> 
> Over my dead CVS access.
> 
> 
> 
> Diego Elio Pettenò — Flameeyes
> flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Could you please reply with some reasoning instead of that kind of
reply? At least for me, it seems pretty authoritative :/

Thanks a lot

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/15/2013 04:56 AM, Vadim A. Misbakh-Soloviov wrote:
> Sometimes I find myself in a situation, when I need to use both
> RESTRICT=fetch for the main distfile and allow fetch for additional ones
> (langpacks, extensions and so on).
> Sometimes it is even impossible to split that additions into separate
> package, since they might want to replace some file (for example, Dear
> Esther's translations).
> 
> So, in that case, I think,  it'd be useful to change SRC_URI behaviour a
> bit:
> 
> for example:
> 
> SRC_URI="
> 	restrict://dearesther-linux-06082013-bin #fetch restrict
> 	linguas_ru? ( http://www.dear-esther.com/translations/DE_Russian.rar )
> 	linguas_hu? ( http://www.dear-esther.com/translations/DE_Hungarian.rar )
>         linguas_hu2? (
> http://www.dear-esther.com/translations/DE_Hungarian2.rar )
> "
> Alternatively it can be even:
> 
> SRC_URI="
> 	restrict+http://foo.bar/moo-123.run # mirror-restrict or specifying a
> link for fetch-restrict (like for oracle-jdk)
> "

I think something like this would be extremely valuable.  Sometimes one
file is fetch restricted and the rest are not and we currently don't
handle that at all.  If you want to write an implementation for it, I
think it's great.
> 
> And, moreover, I guess, SRC_URI can even be used for VCS:
> 
> SRC_URI="
> 	git+ssh://github.com/lol/moo.git
> 	hg+ssh://bitbucket.org/lol/moo
> 	svn+ssh://assembla.com/lol/moo
> "
> 
> And it can also be extendable:
> 
> SRC_URI="
> 	hg+http://prosody.im/trunk
> 	modules? ( hg+https://prosody-modules.googlecode.com/hg )
> "

I don't quite agree with "Over my dead CVS access" but yeah, this isn't
really a great idea or needed.  The current way to fetch live things is
both functional and simple enough to be in very wide use.  There is
currently no need for improvement in my eyes, and I'm not sure this
could be considered improvement anyway.

Thanks,
Zero

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRvIR6AAoJEKXdFCfdEflKns8QAJq4N0VDwoLTda5ptmEXhrH9
O6CBNAvz+f4cG/lA9bKRxqjWfce44KQbSCO/nieabLLNTNEtNn+xbdz5AHGJxEKa
muxJNhHiUNjqN6J9IyXNqlpV1hC0mrxroN9hTL7HnryJKzLXx7t+IIpnjyFZDdho
bw9PH1boAt7YN4FRctoV3ALAXU3zY+v/rJNAoDAwfajteZRipRPEnfGEVeuKjm7o
8PY39eBGmgKzQLoz67RTVVgNwOnsyHeJWJX8XWXaURK/2Lh/jBOdSP23xgh50K20
e4zDdRYHP6YH0vFraIjo9d17NtuuzI3SW78BL8JMHdNbQl7XY5khN/Z/KuKy3ydH
ccQba25Snkuz0tL+DBnpMb5JkLz02Jup2ug6VqTPwCTtCykRvDF9jf0JLEcNfEd2
8Tkqn4Jah5+zqYox0xIxlJmwLvnlH8Jc7OLuZEIEjt4x3tEXf8mDSSpWV90aI+A2
7dHi9ealEPAPTdt7LqHuJ6ic7akPH4o/lTE+Yp/OcSIUrAfWThxiLUkgD3vbBh/E
ZzQFuIqrtptXWP8jGhw01bcqRp6MfOSuCe5G6pEdR0N8Ud5qnyZyPWeMf/1hUxMy
g4RMge28KDscnQy+Z0D0BNGSyYuru5mP+vLnfqKHnUjNzxSSbIXj3F98nXykhVvQ
SyGs/KBmBdtLVGqrqVWl
=gBw2
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Brian Dolbec]

On Sat, 2013-06-15 at 15:05 +0200, Michał Górny wrote:
> Dnia 2013-06-15, o godz. 15:56:53
> "Vadim A. Misbakh-Soloviov" <mva@mva.name> napisał(a):
> 
> > And, moreover, I guess, SRC_URI can even be used for VCS:
> > 
> > SRC_URI="
> > 	git+ssh://github.com/lol/moo.git
> > 	hg+ssh://bitbucket.org/lol/moo
> > 	svn+ssh://assembla.com/lol/moo
> > "
> 
> It simply can't work. Don't even try to implement, it's waste of time.
> Just grep the tree, see how various packages use VCS-es. There's too
> many differences, too many needs and -- most importantly -- VCS-es
> change over time much more quickly than, say, unpackers.
> 

Well, there is an app in gentoo that can already handle every VCS type.
It could easily be modified to handle the above syntax.  The portage
mods would also not be difficult to interface to it.  The BAD!!! part is
that it would require even more time for portage to sort out the VCS
deps that would need to be added to it's dep calculations after checking
the SRC_URI.  

GOD!, it's already getting slower than it was many years ago before
Brian's pkgcore optimizations began to be applied.  Not to mention GB's
of memory and multiple cores now available that wasn't those many years
ago...

The other thing is that would put a mandatory system requirement on
layman which many of the devs would be opposed to. But, there is an open
bug calling for it to be merged with portage...

> Even *if* we get a SRC_URI VCS support that works for all consumers,
> and that'd be awfully hard to do properly, it will eventually stop
> being 'good enough' and require further changes. It will just become
> never-ending story for a minor benefit.
> 

also, agreed

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Rich Freeman]

On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec <dolsen@gentoo.org> wrote:
> The other thing is that would put a mandatory system requirement on
> layman which many of the devs would be opposed to. But, there is an open
> bug calling for it to be merged with portage...

Honestly, native support for overlays is something paludis gets right
- the main tree is just another tree and you prioritize them.  What I
don't like about paludis is that it exposes a lot of implementation
details in its config files that are probably best defaulted away
(unless that has changed), but having /etc/portage/repositories.d with
a bunch of files that each contain a URI and a priority and maybe
other optional parameters would be nice.

Rich

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Luca Barbato]

On 06/15/2013 05:33 PM, Rich Freeman wrote:
> On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec <dolsen@gentoo.org> wrote:
>> The other thing is that would put a mandatory system requirement on
>> layman which many of the devs would be opposed to. But, there is an open
>> bug calling for it to be merged with portage...
> 
> Honestly, native support for overlays is something paludis gets right
> - the main tree is just another tree and you prioritize them.

Not sure it is a great idea in practice.

lu

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Rich Freeman]

On Sat, Jun 15, 2013 at 11:43 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> On 06/15/2013 05:33 PM, Rich Freeman wrote:
>> On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec <dolsen@gentoo.org> wrote:
>>> The other thing is that would put a mandatory system requirement on
>>> layman which many of the devs would be opposed to. But, there is an open
>>> bug calling for it to be merged with portage...
>>
>> Honestly, native support for overlays is something paludis gets right
>> - the main tree is just another tree and you prioritize them.
>
> Not sure it is a great idea in practice.

This is how virtually all other distros operate - they ship with a
list of repositories and the user controls which ones are in use.  All
such a change would do is make it easier to manage overlays - you'd
certainly not be required to use them.  Plus, right now with Gentoo
there is no way to set an overlay as being LOWER priority than the
main tree - so that you can grab packages not supported in main from
an overlay but still use the main packages when available.  That is,
unless you set up the overlay as your main tree and set up portage as
an overlay.

The approach paludis uses just seems simpler all-around, minus the
fact that it doesn't provide defaults for internals that need not be
exposed (vdb and such - which admittedly aren't needed by exherbo).

Rich

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1375 bytes --]

On Sat, 15 Jun 2013 15:56:53 +0700
"Vadim A. Misbakh-Soloviov" <mva@mva.name> wrote:
> Sometimes I find myself in a situation, when I need to use both
> RESTRICT=fetch for the main distfile and allow fetch for additional
> ones (langpacks, extensions and so on).
> Sometimes it is even impossible to split that additions into separate
> package, since they might want to replace some file (for example, Dear
> Esther's translations).
> 
> So, in that case, I think,  it'd be useful to change SRC_URI
> behaviour a bit:
> 
> for example:
> 
> SRC_URI="
> 	restrict://dearesther-linux-06082013-bin #fetch restrict
> 	linguas_ru?
> ( http://www.dear-esther.com/translations/DE_Russian.rar )
> linguas_hu?
> ( http://www.dear-esther.com/translations/DE_Hungarian.rar )
> linguas_hu2?
> ( http://www.dear-esther.com/translations/DE_Hungarian2.rar ) "
> Alternatively it can be even:
> 
> SRC_URI="
> 	restrict+http://foo.bar/moo-123.run # mirror-restrict or
> specifying a link for fetch-restrict (like for oracle-jdk)

Syntax-wise, one of the proposals for dealing with the explosion of
*DEPEND variables is a single variable plus labels. The same syntax
could be used here, so you'd do:

    SRC_URI="http://blah/blah restrict: http://blah/other"

and so on, with the usual parentheses for restricting scope of labels.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Sat, 15 Jun 2013 11:51:03 -0400
Rich Freeman <rich0@gentoo.org> wrote:
> The approach paludis uses just seems simpler all-around, minus the
> fact that it doesn't provide defaults for internals that need not be
> exposed (vdb and such - which admittedly aren't needed by exherbo).

I've not heard people ask for defaults like that before. Most people,
when configuring, get these files created automatically for them
anyway, and they're useful to have around so you know what to tweak.

*shrug* It would be trivial to do a per-distribution default config
that gets overridden.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Anthony G. Basile]

On 06/15/2013 11:43 AM, Luca Barbato wrote:
> On 06/15/2013 05:33 PM, Rich Freeman wrote:
>> On Sat, Jun 15, 2013 at 11:24 AM, Brian Dolbec <dolsen@gentoo.org> wrote:
>>> The other thing is that would put a mandatory system requirement on
>>> layman which many of the devs would be opposed to. But, there is an open
>>> bug calling for it to be merged with portage...
>>
>> Honestly, native support for overlays is something paludis gets right
>> - the main tree is just another tree and you prioritize them.
>
> Not sure it is a great idea in practice.
>
> lu
>

There was a period where Zorry and I were working on the hardened 
toolchain off the hardened-dev overlay.  Migrating it back to the tree 
was a pita.  Unless the stuff in the overlay is orthogonal to the main 
tree, you will effectively be creating forks which are not easily 
merged.  Repositories in other distros (eg debian) normally just add new 
.debs.  They don't override deeper structures such as toolchains and 
core utilities.  We can overrride *anything* in the portage tree like 
eclasses making overlays a more serious matter.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Michael Weber]

On 06/15/2013 02:14 PM, Diego Elio Pettenò wrote:
> It's just not going to happen as long as I got CVS access, it's not a?T
> threat or a grandstanding, it's a simple boolean logic statement.
Step away then.

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Diego Elio Pettenò]

On 15/06/2013 22:15, Michael Weber wrote:
>> > It's just not going to happen as long as I got CVS access, it's not a?T
>> > threat or a grandstanding, it's a simple boolean logic statement.
> Step away then.

You know what? I really should just leave and see how people who think
that a live ebild is a nice idea will ruin it. It's not like I depend on
Gentoo for my work anymore.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Diego Elio Pettenò]

On 15/06/2013 22:17, Diego Elio Pettenò wrote:
> You know what? I really should just leave and see how people who think
> that a live ebild is a nice idea will ruin it. It's not like I depend on
> Gentoo for my work anymore.

Oh wait, I already know how that's going to happen.. bug #443448 is a
nice example.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Michael Weber]

On 06/15/2013 11:17 PM, Diego Elio Pettenò wrote:
> On 15/06/2013 22:15, Michael Weber wrote:
>>>> It's just not going to happen as long as I got CVS access, it's not a?T
>>>> threat or a grandstanding, it's a simple boolean logic statement.
>> Step away then.
> 
> You know what? I really should just leave and see how people who think
> that a live ebild is a nice idea will ruin it. It's not like I depend on
> Gentoo for my work anymore.
Fine, we would all benefit from a environment without your snappy
comments and cryptic responses. Seriously, learn some social skill in
your free time.

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Markos Chandras]

On 15 June 2013 22:21, Michael Weber <xmw@gentoo.org> wrote:
> On 06/15/2013 11:17 PM, Diego Elio Pettenò wrote:
>> On 15/06/2013 22:15, Michael Weber wrote:
>>>>> It's just not going to happen as long as I got CVS access, it's not a?T
>>>>> threat or a grandstanding, it's a simple boolean logic statement.
>>> Step away then.
>>
>> You know what? I really should just leave and see how people who think
>> that a live ebild is a nice idea will ruin it. It's not like I depend on
>> Gentoo for my work anymore.
> Fine, we would all benefit from a environment without your snappy
> comments and cryptic responses. Seriously, learn some social skill in
> your free time.
>


Please both of you. Stop it now and take it elsewhere. Consider this a
friendly warning.

--
Regards,
Markos Chandras - Gentoo Linux Developer
http://dev.gentoo.org/~hwoarang

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Diego Elio Pettenò]

On 15/06/2013 22:21, Michael Weber wrote:
> Fine, we would all benefit from a environment without your snappy
> comments and cryptic responses. Seriously, learn some social skill in
> your free time.

See, I cannot exactly voice what my opinion of you is on a public forum,
or I would have done so.

Maybe you should think twice about what _you_ have been doing, rather
than worrying about my social skills.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 06/15/2013 05:12 PM, Rick "Zero_Chaos" Farina wrote:
> There is currently no need for improvement in my eyes, and I'm not
> sure this could be considered improvement anyway.
i.e. git-2.eclass provides support for environment override (and
variables) for branches, commits and repos, for example
EGIT_REPO_URI=<some other fancy git clone>

Hard to cover/encode this functionality in your proposed urls.

These look - by the way - a lot like the "new" packer-4.something git
url in Archlinux/AUR.

"our" VCS eclasses should still be superior in functionality.


++ for global RESTRICT="fetch|mirror" with overrides in both ways on
per url basis as prefix to the protocol, like nomirror+http:// and
fetch+git:// . But this needs tivial (?) adaption in every VCS eclass.


- -- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlG83TcACgkQknrdDGLu8JAq/wEAmUQkeQaLY8FVGZpO9YNShR43
DQ4hrgT1TNSnUQcwzZQBAImK9nurCVcUn4LJSBD0mtCQah2VVo1VfTUzeoMJs1Tt
=B9vk
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Michael Weber]

On 06/15/2013 11:24 PM, Markos Chandras wrote:
> Please both of you. Stop it now and take it elsewhere. Consider this a
> friendly warning.
Agreed. Sorry for my impulsive response.
I don't say thanks for the warning, but for your counseling of the
mailing list.

I'm on a borderline between advocation against "abusive" or
"destructive" behavior leeding to the last two retirements and
just leaving these people.

I hate the overlay/fork symptomatic, and I have put a lot of effort into
making Gentoo into my personal understanding of Linux, but
i'm considering stepping down to a overlay basis and avoid all the
bitching and alpha-male stupidity.

Bye,

   Michael

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/15/2013 05:15 PM, Michael Weber wrote:
> On 06/15/2013 02:14 PM, Diego Elio Pettenò wrote:
>> It's just not going to happen as long as I got CVS access, it's
>> not a?T threat or a grandstanding, it's a simple boolean logic
>> statement.
> Step away then.
> 
Okay now we are grandstanding the grandstanding.  Please, let's keep
to technical issues and not intentionally antagonize people.

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRvOz1AAoJEKXdFCfdEflK3UEP/i/Y+LCRRkZ3w6D+45BVhmVr
VDpEiTZMt1DhJpm/Wu9eYwyfB/dVDHu027KNRWlyrPnBA/nwo0KqYR8lnqZFVcvS
mLXf5dIy0MarVO1AsbyOFpbkSfujhlZwFLOl7lCk2fh/biPVdMjaSnOoP9K1Ii0X
mhrh2B84kSgRgsLonp1pMdtP4u+jnpMxA82UOxe62tzw04WroOh1BZsc7opQM3t/
ex7td5lfkQJv8kH03+GoxhV1svORo9zoXpbQtvPGvYDBOGY2l/6kmDMCOOZKVl9A
h1xC4VGUPElp6h88lHkMXOfR6RazdXt380e/vXwONdc3ciaG1Z/ilNAVv1DLZTFD
rowXf0imuo9INCwsTPYPwWYP/wfHfZ3TMPkhz7j9BV7mJqkfbvpI6uPU5CJNQNls
I79N0RBWp+oeMVF9CXee2s7JEmwOAvsMPPTpe0fI/UHJntnEBTWdCOlnfyFK2C/9
9/BlI3Jnc6y/bDCzleavEEWql7ZDDUac6JBC3hl29lbqrIulLk5HzI7FgfP/8x+/
6482AeNlpE/xPXuTiwEK0NWeHtbECzqA8u2XA3EGFzEQ9bZQ0xxojH+Z+XZW6ak0
Na6ShPu3P0PNH0PYCazgS5kfyvpoS0fXpPyfO1UVNpGi4bQx1DjKBlgWstdrgh7b
PKVCPTD/xh/ia6qHzbjM
=EP39
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Zac Medico]

On 06/15/2013 06:05 AM, Michał Górny wrote:
> Dnia 2013-06-15, o godz. 15:56:53
> "Vadim A. Misbakh-Soloviov" <mva@mva.name> napisał(a):
>
>> And, moreover, I guess, SRC_URI can even be used for VCS:
>>
>> SRC_URI="
>> 	git+ssh://github.com/lol/moo.git
>> 	hg+ssh://bitbucket.org/lol/moo
>> 	svn+ssh://assembla.com/lol/moo
>> "
>
> It simply can't work. Don't even try to implement, it's waste of time.
> Just grep the tree, see how various packages use VCS-es. There's too
> many differences, too many needs and -- most importantly -- VCS-es
> change over time much more quickly than, say, unpackers.
>
> Even *if* we get a SRC_URI VCS support that works for all consumers,
> and that'd be awfully hard to do properly, it will eventually stop
> being 'good enough' and require further changes. It will just become
> never-ending story for a minor benefit.

How about it we add a src_fetch phase, so that the VCS intricacies can 
be delegated to ebuilds/eclasses (like they are now, but without having 
to abuse src_unpack). If we include a way for src_fetch to communicate 
changes in VCS revisions to the package manager, then we'll be able to 
integrate functionality like smart-live-rebuild directly into the 
package manager (as discussed in bug 182028 [1]).

[1] http://bugs.gentoo.org/show_bug.cgi?id=182028
-- 
Thanks,
Zac

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Arfrever Frehtes Taifersar Arahesis]

2013-06-15 17:51 Rich Freeman napisał(a):
> Plus, right now with Gentoo there is no way to set an overlay as being LOWER
> priority than the main tree - so that you can grab packages not supported in
> main from an overlay but still use the main packages when available.

Portage has been supporting setting of priority in /etc/portage/repos.conf for about 2.7 years.

$ cat /etc/portage/repos.conf
[name_of_overlay]
priority = -1001

(`emerge --info -v` shows repositories with their priorities.)

--
Arfrever Frehtes Taifersar Arahesis

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Luca Barbato]

On 06/16/2013 02:24 AM, Zac Medico wrote:
> How about it we add a src_fetch phase, so that the VCS intricacies
> can be delegated to ebuilds/eclasses (like they are now, but without
> having to abuse src_unpack). If we include a way for src_fetch to
> communicate changes in VCS revisions to the package manager, then
> we'll be able to integrate functionality like smart-live-rebuild
> directly into the package manager (as discussed in bug 182028 [1]).

Sounds interesting.

Still please notice that the initial and misdelivered point about live
ebuild being NOT for everybody beside who develops software should be clear.

lu

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Georg Rudoy]

2013/6/16 Zac Medico <zmedico@gentoo.org>:
> How about it we add a src_fetch phase, so that the VCS intricacies can be
> delegated to ebuilds/eclasses (like they are now, but without having to
> abuse src_unpack). If we include a way for src_fetch to communicate changes
> in VCS revisions to the package manager, then we'll be able to integrate
> functionality like smart-live-rebuild directly into the package manager (as
> discussed in bug 182028 [1]).

As a side note from a developer of an app that keeps various loosely
coupled modules in one repo — it'd be great if there would be a way to
also tell whether the changed revision actually affects the given
package. The default, of course, should be to assume that every change
in the repo affects a given package, but when it can be proved that
package doesn't need to be rebuilt — why bother rebuilding it? Of
course, the task of the proof lies on exact ebuild maintainer.

--
  Georg Rudoy
  LeechCraft — http://leechcraft.org

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Vadim A. Misbakh-Soloviov]

[-- Attachment #1: Type: text/plain, Size: 552 bytes --]

I'd like that behaviour!


16.06.2013 07:24, Zac Medico пишет:
> How about it we add a src_fetch phase, so that the VCS intricacies can
> be delegated to ebuilds/eclasses (like they are now, but without having
> to abuse src_unpack). If we include a way for src_fetch to communicate
> changes in VCS revisions to the package manager, then we'll be able to
> integrate functionality like smart-live-rebuild directly into the
> package manager (as discussed in bug 182028 [1]).
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=182028



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[gentoo-dev] Re: [RFC] SRC_URI behaviour

[Michael Palimaka]

On 16/06/2013 10:24, Zac Medico wrote:
> How about it we add a src_fetch phase, so that the VCS intricacies can
> be delegated to ebuilds/eclasses (like they are now, but without having
> to abuse src_unpack). If we include a way for src_fetch to communicate
> changes in VCS revisions to the package manager, then we'll be able to
> integrate functionality like smart-live-rebuild directly into the
> package manager (as discussed in bug 182028 [1]).
>
> [1] http://bugs.gentoo.org/show_bug.cgi?id=182028

This sounds interesting. It definitely would be nice to have proper 
package manager support for VCS.

I don't think that this will somehow "legitimise" live ebuilds. We use 
policies to prevent inappropriate things from entering the tree, not by 
preventing tools that might facilitate it.

Best regards,
Michael

Re: [gentoo-dev] [RFC] SRC_URI behaviour

[Rick "Zero_Chaos" Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/15/2013 08:24 PM, Zac Medico wrote:
> On 06/15/2013 06:05 AM, Michał Górny wrote:
>> Dnia 2013-06-15, o godz. 15:56:53
>> "Vadim A. Misbakh-Soloviov" <mva@mva.name> napisał(a):
>>
>>> And, moreover, I guess, SRC_URI can even be used for VCS:
>>>
>>> SRC_URI="
>>>     git+ssh://github.com/lol/moo.git
>>>     hg+ssh://bitbucket.org/lol/moo
>>>     svn+ssh://assembla.com/lol/moo
>>> "
>>
>> It simply can't work. Don't even try to implement, it's waste of time.
>> Just grep the tree, see how various packages use VCS-es. There's too
>> many differences, too many needs and -- most importantly -- VCS-es
>> change over time much more quickly than, say, unpackers.
>>
>> Even *if* we get a SRC_URI VCS support that works for all consumers,
>> and that'd be awfully hard to do properly, it will eventually stop
>> being 'good enough' and require further changes. It will just become
>> never-ending story for a minor benefit.
> 
> How about it we add a src_fetch phase, so that the VCS intricacies can
> be delegated to ebuilds/eclasses (like they are now, but without having
> to abuse src_unpack). If we include a way for src_fetch to communicate
> changes in VCS revisions to the package manager, then we'll be able to
> integrate functionality like smart-live-rebuild directly into the
> package manager (as discussed in bug 182028 [1]).
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=182028

+1 on src_fetch in or out of the context of this thread.

+1 on more granular fetch/mirror restrictions

+-0 on VCS in SRC_URI, as I already stated I'm fine with the current
functionality (aside from a vast desire for src_fetch phase).

- -Zero
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRvc4cAAoJEKXdFCfdEflK990P/267Ej2p26SvRGItzFHtHakH
EwDEQcLxfykfqs1p1AWjR2O9e7ZvW7PaF9EyFdypY0MxAu0faB24ek4OKGD4842L
VbkQFXRjSOu1e+bLvQERofiVJ2/qSJZmg/phBsLwQiT0GVTm6ZXykZHSjfyTSALG
6ip+bhwUnYGGmxs8oudb7abBy7HfqhFlA6GTnyonqeRXre4QxfWFi1Yup/mRFuWp
XFwEoBe9t/95DBiXfjbvO5b6rlVEsChXuxELDUgP1dTdXTYKVRohs0lU6uZqlJkz
RY+8p8bJDsZas0Ucw7+7ePb93mH+XCKz5bvMrz2YhEM//NTOC6QY9+F6iy/NevTp
FNJeBCYUNKPpGzy4bm1649vDCqG51WK9iG8qtYO5G0y2QpkGZugUfALwalXK7L3M
eThjhlGrn0LZvGXxkYNtHgimFg3VWDJXJLHipMkP5dUqC5t4HEaEqgdGTCpzwuka
IUAahKdFLd3EZBlc3MHkYwuzfa0/MayOFiMcHKVV2+ONa5FcwkO8Rg6QJk5Xb7A1
NpPU87VampYERtaNcJKVACl8wR8Pltg4Y5xyz5Dgs+ga/gLvun6VePPO3WvKrAsS
UirS6VqysSEFaZTFotW0LAN6N8+Mll90gjRRgJxaQcGy1IiZ7VXYGzb8Q9nRWL9n
1PD6mk8hNr9C3aV14QzM
=7DTn
-----END PGP SIGNATURE-----