Ticket #808 (closed support-request: wontfix)

Opened 10 years ago

Last modified 10 years ago

repositories can't contain symlinked files while fetching

Reported by: alx_me Owned by:
Priority: Sometime Milestone:
Component: clients/paludis Version: 0.42.2
Keywords: symlink Cc:
Blocked By: Blocking:
Distribution: Gentoo


FSEntry::file_size() const does not calculate size of symlinked files

Change History

comment:1 Changed 10 years ago by ciaranm

This is probably intentional, because it's probably not really legal for those files to be symlinks. What's the use case for it?

comment:2 Changed 10 years ago by alx_me

Why not? It's a regular practic using symlink in UNIX, no? It's should be legal cause regular file standing for this symlink has normal control summs and size. If asked about use case: we have cetralized r/o distfiles on our server. And local distfiles r/w then it needed.

And one more: emerge eats it ;-)

comment:3 Changed 10 years ago by ciaranm

I'm not sure that it is legal, because PMS says in various places that the thing in DISTDIR is a "file", and it doesn't explicitly allow symlinks. Thus, ebuilds don't have to support the use of symlinks there, so the package manager shouldn't be allowing it.

Why don't you use hard links? That way the difference is invisible to the ebuild.

comment:4 Changed 10 years ago by alx_me

Keyword is _server_. Not same partition. Hardlink is impossible. ebuild has no idea about file placing at all. it contains only URLs where tarball may be found. anything else handled by emerge/portage utils. the question is: why not? i know that symlinks are explicitly prohibited in, for example, FSEntry::file_size(), as i written before. for my mind its a simple changing that i need to get pleasure.

what would say your PMS about symlinks in random places of any UNIX,GNU/Linux,BSD,...: ls -al /usr/lib | grep -- '->' | grep /

comment:5 Changed 10 years ago by ciaranm

Ebuilds *do* know about file placing. Ebuilds deal directly with things in DISTDIR, and the specification says that they can expect things in there to be files. If you think the specification is too tight in there, the correct procedure is to demonstrate conclusively that nothing relies upon the behaviour you wish to have changed, and then request comments on the gentoo-dev mailing list to ensure that a change in wording to the specification is acceptable.

In any case, the fix would not be to change FSEntry, since FSEntry is used by an awful lot of things, many of which (e.g. merging files to /) rely upon the exact behaviour it already provides.

comment:6 Changed 10 years ago by alx_me

Ok let it be multiple distdir, or distdir=PATH1:PATH2:... . ok? it's even better. may be it's already done?

comment:7 Changed 10 years ago by alx_me

My be I'm wrong, but for my mind it's a usual practice to work transparently throw symlinks. It was a surprise for me then a discover such misunderstanding.

comment:8 Changed 10 years ago by ciaranm

Multiple distdirs definitely isn't going to fly, since it would require substantial ebuild changes.

And no, symlinks are in no way transparent. Hardlinks pretty much are, except if you go out of your way to look for them, but symlinks alter behaviour of all kinds of things.

comment:9 Changed 10 years ago by alx_me

hardlinks are transparent because they are the exact same file with multiple instances in dir's inodes. such effect could not called transparency at all :-D.

comment:10 Changed 10 years ago by ciaranm

But even hardlinks aren't entirely transparent, since programs can work out whether something's hardlinked if they need to (and Paludis does in places, so that hardlinks aren't merged as multiple copies). Symlinks, on the other hand, require code to explicitly be aware of them and to behave differently depending upon whether something's a symlink or not in an awful lot of places...

comment:11 Changed 10 years ago by alx_me

There is no need in ebuilds changing if DISTDIR and same substitutions evaluate as special case.

cp "${DISTDIR}/arc4random.c.${ARC4_VERSION}" "${S}/arc4random.c"

brings to searching for ${DISTDIR1}/arc4random.c.${ARC4_VERSION}, ${DISTDIR2}/arc4random.c.${ARC4_VERSION}, ... .

Well I see, it is a complex task.

simlinks are more obvious.

comment:12 Changed 10 years ago by alx_me

Thanks for attention. I will make a local patch. ;-)

comment:13 Changed 10 years ago by ciaranm

  • Status changed from new to closed
  • Resolution set to wontfix


Note: See TracTickets for help on using tickets.