Bug 334275 – support file:// in SRC_URI

• Product: Gentoo Hosted Projects
• Status: RESOLVED NEEDINFO

[Description Helmut Jarausch 2010-08-24 12:08:35 UTC]

I'd like to use portage even for local packages, i.e.
I have a source package  MY_Pack.tar.bz2 in, say, /usr/local/Src

Now, I'd like to specify

SRC_URI="file:///usr/local/Src/MY_Pack.tar.bz2"
in my ebuild 
but then isn't recognized by portage-2.2_rc68

Please consider adding this feature,
Helmut.


Reproducible: Always

[Comment 1 Brian Harring (RETIRED) 2010-12-30 16:48:35 UTC]

is there a reason this you can't use RESTRICT=mirror, and symlink the distfile into $DISTDIR ?

That accomplishes the same... personally I don't like file:/// in an ebuild since it should be specifying the remote location, not used to avoid existing DISTDIR tricks...

[Comment 2 SpanKY 2011-11-22 20:20:41 UTC]

i don't think we should be restricting supported URI's based on "can these be used in the tree".  people write local/internal ebuilds all the time, and their own circumstances don't always lend themselves to flexibility.

the file:// URI spec is fairly well understood and should be trivial to support.

[Comment 3 Michał Górny 2011-11-22 20:30:21 UTC]

(In reply to comment #2)
> i don't think we should be restricting supported URI's based on "can these be
> used in the tree".  people write local/internal ebuilds all the time, and their
> own circumstances don't always lend themselves to flexibility.
> 
> the file:// URI spec is fairly well understood and should be trivial to
> support.

Doesn't seem like a candidate for PMS to me. Rather Portage-specific feature.

[Comment 4 SpanKY 2011-11-22 20:45:45 UTC]

Brian is fairly intent on these not being portage specific, and i see no reason to keep this out of PMS

[Comment 5 Ciaran McCreesh 2011-11-22 20:52:34 UTC]

There's no way for an ebuild to use these correctly, though. We shouldn't be specifying things that have no legitimate use.

[Comment 6 Michał Górny 2011-11-22 21:20:22 UTC]

(In reply to comment #4)
> Brian is fairly intent on these not being portage specific, and i see no reason
> to keep this out of PMS

I see PMS as an intent to keep ebuilds portable. Ebuilds relying on local paths can't be portable by definition. There's no point in PMS saying about those.

[Comment 7 SpanKY 2011-11-22 22:12:50 UTC]

yes, portable *across package managers*.  there is no (nor should there be any) restriction on what's supported based on "is this in the main Gentoo portage tree".

[Comment 8 Michał Górny 2013-08-30 11:06:48 UTC]

Well, you still can write something like:

  src_unpack() {
    unpack /usr/local/....
  }

which seems to be cleaner than 'fetching' a local file.

[Comment 9 Arfrever Frehtes Taifersar Arahesis 2013-08-30 13:59:36 UTC]

(In reply to Michał Górny from comment #8)
> you still can write something like:
> 
>   src_unpack() {
>     unpack /usr/local/....

/usr/lib/portage/bin/phase-helpers.sh:
  unpack() {
    ...
      elif [[ ${x} == "/"* ]] ; then
        die "Arguments to unpack() cannot be absolute"

[Comment 10 Michał Górny 2013-08-30 14:56:21 UTC]

Oh, I see that 'unpack' is non-intuitive and braindead by design...

[Comment 11 Ulrich Müller 2013-09-01 07:23:15 UTC]

(In reply to Michał Górny from comment #8)
> Well, you still can write something like:
> 
>   src_unpack() {
>     unpack /usr/local/....
>   }
> 
> which seems to be cleaner than 'fetching' a local file.

No. Things in SRC_URI get proper digest checksums in Manifest, unpack on random paths doesn't. This may have security implications, too.

[Comment 12 Ulrich Müller 2013-09-04 17:53:09 UTC]

(In reply to SpanKY from comment #2)
> i don't think we should be restricting supported URI's based on "can these
> be used in the tree".  people write local/internal ebuilds all the time, and
> their own circumstances don't always lend themselves to flexibility.
> 
> the file:// URI spec is fairly well understood and should be trivial to
> support.

I tend to agree with Mike. "file" is a standard scheme (described in RFC 1738), and implementation should be trivial. Supporting it in SRC_URI is cleaner than bypassing fetch (and checksum verification) via src_unpack tricks.

Of course it cannot be used in the tree.

[Comment 13 Ulrich Müller 2013-09-21 15:50:29 UTC]

If someone cares enough to provide a patch for Portage, then I'll add this to the list of tentative features for the next EAPI.

[Comment 14 Michał Górny 2014-09-06 21:50:21 UTC]

No reply for almost a year. Assuming interest was lost (or never were high enough to bring a patch :)).

[Comment 15 Ulrich Müller 2014-09-06 22:18:37 UTC]

This is an unintrusive feature, and I don't see why it shouldn't be added to the spec, provided that there will be an implementation.

The NeedPatch keyword is set, so I don't see any need to close this bug.

[Comment 16 Zac Medico 2015-07-02 19:42:25 UTC]

*** Bug 553768 has been marked as a duplicate of this bug. ***

[Comment 17 Ulrich Müller 2017-09-08 19:01:33 UTC]

No progress since 3 years. Closing.