[gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Robin H. Johnson]

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

If you have an ebuild with a non-standard pkg_nofetch, please ensure
that you use $SRC_URI instead of $A!

This is because if you have FEATURES=mirror or FEATURES=cvs, attempts to
download all of the source files for digesting or verification will hit
pkg_nofetch and $A is only the subset of $SRC_URI, causing misleading
messages to be displayed about what needs to be downloaded still.

Plasmaroo: could you perhaps change this in the devmanual?

I'll be looking through the tree to fix any existing occurrences of this.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Donnie Berkholz]

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

Robin H. Johnson wrote:
> If you have an ebuild with a non-standard pkg_nofetch, please ensure
> that you use $SRC_URI instead of $A!
> 
> This is because if you have FEATURES=mirror or FEATURES=cvs, attempts to
> download all of the source files for digesting or verification will hit
> pkg_nofetch and $A is only the subset of $SRC_URI, causing misleading
> messages to be displayed about what needs to be downloaded still.
> 
> Plasmaroo: could you perhaps change this in the devmanual?
> 
> I'll be looking through the tree to fix any existing occurrences of this.

Displaying $SRC_URI is worse for the user, because it displays this
weird dependency tree containing USE flags that they should not need to
decipher.

I don't consider this something that should be "fixed."

Thanks,
Donnie


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

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Robin H. Johnson]

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

On Mon, Jul 03, 2006 at 07:13:35PM -0700, Donnie Berkholz wrote:
> Robin H. Johnson wrote:
> > If you have an ebuild with a non-standard pkg_nofetch, please ensure
> > that you use $SRC_URI instead of $A!
> > 
> > This is because if you have FEATURES=mirror or FEATURES=cvs, attempts to
> > download all of the source files for digesting or verification will hit
> > pkg_nofetch and $A is only the subset of $SRC_URI, causing misleading
> > messages to be displayed about what needs to be downloaded still.
> > 
> > Plasmaroo: could you perhaps change this in the devmanual?
> > 
> > I'll be looking through the tree to fix any existing occurrences of this.
> Displaying $SRC_URI is worse for the user, because it displays this
> weird dependency tree containing USE flags that they should not need to
> decipher.
> 
> I don't consider this something that should be "fixed."
In that case, neither behavior is correct.

Additionally, you should talk to the portage team and get the master
ebuild.sh changed, because the stock pkg_nofetch there uses SRC_URI.

This is the existing default pkg_nofetch from ebuild.sh:
pkg_nofetch() {
    [ -z "${SRC_URI}" ] && return
    echo "!!! The following are listed in SRC_URI for ${PN}:"
    local x
    for x in $(echo ${SRC_URI}); do
        echo "!!!   ${x}"
    done
}

When FEATURES=mirror, and you try to fetch, it does indeed contain unevaluated
USE flags. However for FEATURES=-mirror, the content of it is correct - no USE
flags at all.

Maybe a two-part solution is in order here then:
1. Change portage behavior regarding the value of SRC_URI during fetch with
   FEATURES=mirror to not contain any conditionals.
2. Change all ebuilds to use SRC_URI in pkg_nofetch

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Donnie Berkholz]

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

Robin H. Johnson wrote:
> When FEATURES=mirror, and you try to fetch, it does indeed contain unevaluated
> USE flags. However for FEATURES=-mirror, the content of it is correct - no USE
> flags at all.
> 
> Maybe a two-part solution is in order here then:
> 1. Change portage behavior regarding the value of SRC_URI during fetch with
>    FEATURES=mirror to not contain any conditionals.

Also FEATURES=cvs, no?

> 2. Change all ebuilds to use SRC_URI in pkg_nofetch

Sure, as long as SRC_URI == A for the normal (non-cvs|mirror) case.

Thanks,
Donnie


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

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Zac Medico]

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

Robin H. Johnson wrote:
> When FEATURES=mirror, and you try to fetch, it does indeed contain unevaluated
> USE flags. However for FEATURES=-mirror, the content of it is correct - no USE
> flags at all.

Are you sure about the SRC_URI being different?  I don't see anything in the code that causes the SRC_URI to change depending on FEATURES, and a quick test doesn't seem to reproduce that behavior.

If a version of SRC_URI that has all the conditionals evaluated is needed in the ebuild environment, then I think we should use a new variable name.  Otherwise, it's ambiguous.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEqsLl/ejvha5XGaMRAj9EAJ9rpUhdnz1BW269q/bRNt9tDgeL3QCgwz3w
1shmUQyPJlPqkhHhU2P28SU=
=1W8l
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Robin H. Johnson]

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

On Tue, Jul 04, 2006 at 12:35:04PM -0700, Zac Medico wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robin H. Johnson wrote:
> > When FEATURES=mirror, and you try to fetch, it does indeed contain unevaluated
> > USE flags. However for FEATURES=-mirror, the content of it is correct - no USE
> > flags at all.
> Are you sure about the SRC_URI being different?  I don't see anything
> in the code that causes the SRC_URI to change depending on FEATURES,
> and a quick test doesn't seem to reproduce that behavior.
Sorry, you're right, my earlier testcase had a bug that caused me to
miss it.

> If a version of SRC_URI that has all the conditionals evaluated is
> needed in the ebuild environment, then I think we should use a new
> variable name.  Otherwise, it's ambiguous.
Sure, I don't object to to a new variable.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Marius Mauch]

Zac Medico schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Robin H. Johnson wrote:
>> When FEATURES=mirror, and you try to fetch, it does indeed contain unevaluated
>> USE flags. However for FEATURES=-mirror, the content of it is correct - no USE
>> flags at all.
> 
> Are you sure about the SRC_URI being different?  I don't see anything in the code that causes the SRC_URI to change depending on FEATURES, and a quick test doesn't seem to reproduce that behavior.
> 
> If a version of SRC_URI that has all the conditionals evaluated is needed in the ebuild environment, then I think we should use a new variable name.  Otherwise, it's ambiguous.

Doesn't $AA already satisfy the requirements?

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Zac Medico]

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

Marius Mauch wrote:
> Zac Medico schrieb:
>> If a version of SRC_URI that has all the conditionals evaluated is
>> needed in the ebuild environment, then I think we should use a new
>> variable name.  Otherwise, it's ambiguous.
> 
> Doesn't $AA already satisfy the requirements?

Well, I think AA only contains file names, rather than the full URIs.  So, that's not quite the same as SRC_URI with all of it's conditionals evaluated.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFErACf/ejvha5XGaMRAn6vAJ9/SZoxChvgwKnH4NSUdkbwUFL9GgCfe9hH
L4piCkwGPQ5Iflg0Yy+KAB0=
=F4My
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Marius Mauch]

Zac Medico schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Marius Mauch wrote:
>> Zac Medico schrieb:
>>> If a version of SRC_URI that has all the conditionals evaluated is
>>> needed in the ebuild environment, then I think we should use a new
>>> variable name.  Otherwise, it's ambiguous.
>> Doesn't $AA already satisfy the requirements?
> 
> Well, I think AA only contains file names, rather than the full URIs.  So, that's not quite the same as SRC_URI with all of it's conditionals evaluated.

It's the same as $A, just for all entries instead of "enabled" entries.
So for URIs we'd need two new variables.
Thinking about it it might be more useful to provide two generic bash 
functions to parse and evaluate DEPEND-like strings in portageq for 
example instead of special casing SRC_URI here.

Marius
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Mike Frysinger]

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

On Monday 03 July 2006 21:00, Robin H. Johnson wrote:
> If you have an ebuild with a non-standard pkg_nofetch, please ensure
> that you use $SRC_URI instead of $A!
>
> This is because if you have FEATURES=mirror or FEATURES=cvs, attempts to
> download all of the source files for digesting or verification will hit
> pkg_nofetch and $A is only the subset of $SRC_URI, causing misleading
> messages to be displayed about what needs to be downloaded still.

whats the problem then ?  the user shouldnt have to download all the files in 
SRC_URI if his USE flags wont need some of it

SRC_URI="foo.tar.bz2 bar? ( bar.tar.bz2 )"

a user with USE=-bar should not have to download bar.tar.bz2 ... if they do, 
it's a portage bug ... fix portage, dont make ebuilds ugly
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Mike Frysinger]

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

On Tuesday 04 July 2006 14:45, Mike Frysinger wrote:
> On Monday 03 July 2006 21:00, Robin H. Johnson wrote:
> > If you have an ebuild with a non-standard pkg_nofetch, please ensure
> > that you use $SRC_URI instead of $A!
> >
> > This is because if you have FEATURES=mirror or FEATURES=cvs, attempts to
> > download all of the source files for digesting or verification will hit
> > pkg_nofetch and $A is only the subset of $SRC_URI, causing misleading
> > messages to be displayed about what needs to be downloaded still.
>
> whats the problem then ?

sorry, i just re-read your message ... perhaps a better fix would be to not 
force people to download all the packages when something has fetch 
restrictions ?
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Robin H. Johnson]

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

On Tue, Jul 04, 2006 at 03:32:47PM -0400, Mike Frysinger wrote:
> sorry, i just re-read your message ... perhaps a better fix would be to not 
> force people to download all the packages when something has fetch 
> restrictions ?
That's not an option if you are re-digesting the package (FEATURES=cvs).
You need all of the source files, and pkg_nofetch still displays the
wrong thing.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] pkg_nofetch: $A vs. $SRC_URI

[Mike Frysinger]

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

On Tuesday 04 July 2006 16:10, Robin H. Johnson wrote:
> On Tue, Jul 04, 2006 at 03:32:47PM -0400, Mike Frysinger wrote:
> > sorry, i just re-read your message ... perhaps a better fix would be to
> > not force people to download all the packages when something has fetch
> > restrictions ?
>
> That's not an option if you are re-digesting the package (FEATURES=cvs).
> You need all of the source files, and pkg_nofetch still displays the
> wrong thing.

that was also implied ... dont redigest files you dont have when dealing with 
nofetch packages
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]