Hello, Recent versions of genkernel use DISTDIR cache directory in order to store sources of runtime dependencies. The DISTDIR directory is CACHE and not persistence storage, a system with empty DISTDIR should be fully operative. Several solutions may be implemented: 1. Copy sources during emerge genkernel to alternate location (as it was in previous releases). 2. Add emerge --fetchonly genkernel at genkernel to update DISTDIR. 3. As you don't like to use gentoo solutions (2), you can implement your own fetch if files are missing.
I really can't help it if you've removed files that have been downloaded for you for your own convenience. It is up to you to configure your software properly on your system. We (genkernel) don't fetch files, at all. The *ebuild* fetches files on a Gentoo system, but the ebuild is *not* a part of the genkernel application. The ebuild is Gentoo-specific, genkernel is not. The default DISTDIR in genkernel.conf is the default Gentoo DISTDIR for convenience's sake. If you clear this directory without updating genkernel, you've broken your own setup, which isn't my fault. That being said, genkernel *should* check for the files and exit, rather than executing and failing. *** This bug has been marked as a duplicate of bug 219297 ***
Hello, Please feel free to reassign this to genkernel ebuild maintainer. It is still the same bug tracking system... Oh... And I guess you will also handle this. Updated title and description: The genkernel ebuild should not use DISTDIR to store sources for genkernel future use, it should copy them into $ROOT, in order to make sure genkernel can use these files even if user clears the DISTDIR cache. If you want I can open a new bug for this.
Do you even read what I write? Why do you insist on reopening bugs where I've already explained what I'm going to do? Is it just because I didn't accept exactly what you want? Please lose the attitude, too. From the very beginning of this bug you've been rather aggressive towards me. Please stop. I don't care for you to explain yourself, since your reasons don't matter, only your words/actions. Anyway, I already said what I was planning on doing, but since you're insisting on reopening this bug, I'm leaving it open until I implement the changes that I want.
>That being said, genkernel >*should* check for the files and exit, rather than executing and failing. Why EXIT? It should *WORK* by either downloading the files or using files that are kept in none cache directory. I don't know any other software/ebuild in tree that use files in DISTDIR after merge. This is the first case. If it had been done by none gentoo aware upstream I would had understood... But you aware that DISTDIR is cache and can be erased, and you use it anyway as persistent storage. There is no escalation mechanism in Gentoo... This is bad for our community... And once again taking this personally is not a solution for our users.
Listen, I've tried to explain to you several times that I have my own plans and goals for genkernel and that I am not required to accept your suggestions. Quite frankly, I'm getting tired of your repeated accusations and poor attitude. I've been rather understanding towards you on this, but my patience can only extend so far. Also, please point out the policy/document that explains that DISTDIR is a cache and non-persistent? Yes, users can clear it, just like they can clear *any other* directory on their system. As I tried to explain previously, the usage of DISTDIR is simply a convenience for Gentoo users. Anyone using tools like eclean would *not* have these files removed for them. I see nothing that mentions DISTDIR being a cache. All I can find is this, from the Handbook (http://www.gentoo.org/doc/en/handbook/hb-portage-files.xml): Source Code Application source code is stored in /usr/portage/distfiles by default. This location is defined by the DISTDIR variable. Now, on the exact same page is: Portage Cache The Portage cache (with modification times, virtuals, dependency tree information, ...) is stored in /var/cache/edb. This location really is a cache: you can clean it if you are not running any portage-related application at that moment. Wouldn't it make sense to list that DISTDIR is a cache and non-persistent here if it is expected to be treated as such? I'd think so. At any rate, we've got a solution in the works.
Also, the *ebuild* uses DISTDIR exactly as it was meant to, via SRC_URI and the package manager. In fact, the ebuild doesn't even touch the files.
> Also, the *ebuild* uses DISTDIR exactly as it was meant to, via SRC_URI and the > package manager. In fact, the ebuild doesn't even touch the files. Right... The ebuild uses this to download the files. But if the solution after merge needs these files, these should be available in a location outside portage DISTDIR. *PLEASE* name one more package (*EBUILD*) in tree that requires files available in DISTDIR after merge or even unpack stage complete. All you need to do is during src_unpack() copy files from DISTDIR into your own location, for example /usr/share/${PN}/sources. I am CC dev-portage, qa maybe you can talk in more polite way with other people.
Is it really necessary to be such an ass? Would you be this same way to an upstream maintainer? Anyway, I've committed a change that moves the distfiles to /var/cache/genkernel/src and checks to make sure the files are there when genkernel is run. It'll bail with an error message if they aren't. This will be in the next _preX release.
> Is it really necessary to be such an ass? Would you be this same way to an > upstream maintainer? It has nothing to do with upstream maintainer... Apparently it has with ebuild maintainer. But this attitude is unique to you guys. Anyway, Correct me if I am wrong again... A user is permitted to clear /var/cache and expect his system continue working. All files in /var/cache can be regenerated from on-system resources on need basis. Placing sources in /var/cache without genkernel actually support downloading these when needed does not use the /var/cache correctly. Please consider putting this in a persistence location: /var/lib, /usr/share Thanks!
Filesystem Hierarchy Standard 5.5 /var/cache : Application cache data 5.5.1 Purpose /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. The data must remain valid between invocations of the application and rebooting the system. Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories.
The ability to refetch a missing distfile will come later. For now, this is what you get. Live with it.
Alon, I'm sick of your constant attacks on me and my team. I've asked you to stop, yet you continue to push your personal agendas in an uncooperative and self-important manner. Well, I'm through being nice to you. I have tried with all of my patience to understand why you're so engrossed in everything being done exactly the way that you want it. Guess what? That's not going to happen. You asked us to change the location because you didn't like it, so we did. Now, you're wanting us to change it *again* because you don't like where we put it? Sorry, but it's not my job to appease you. At this point, I simply ask you to stop trying to interact with me and my team, since you've made it painfully clear that you're incapable of doing so without copping and attitude. Good day.
DevRel: Can you *please* do something about this? It's well past being old and I simply don't have the time nor the energy to combat this sort of continued behavior. Thanks...
OK... Your call. devrel, please review some more examples to get better view. bug#182065, bug#177626, bug#156431, bug#195666, bug#156445, bug#220111 (this one). wolf31o2: You are free to give some more examples. devral,please also review "How we address bugs" by me from Aug 30, 2007 9:45 PM at gentoo-core (I don't know if there is an archive). How a simple technical issue becomes very fast personal with no reason.
Whilst attempting to be impartial I note you're basically saying "Change this!" without being a part of the process, somewhat akin to writing to Microsoft and saying "zomg Internet Explorer doesn't do this. Implement now, or I cry". I'd say valid reasons have been given by Chris for why it's handled the current way, and the Handbook (http://www.gentoo.org/doc/en/handbook/hb-portage-files.xml) seems to support this -- your attitude is thus extremely unhelpful. If a technical decision needs to be made, you would be free to bring this trivial argument / "issue" to attention of Council, as they are the overall arbiter of which technical direction we as a project takes. The fact you're being unreasonable, uncooperative and aggressive towards Chris and Andrew is the only thing here which should be looked at by Developer Relations. As is the nature of open source, you're more than free to fork. "Fork off :)".
Readding dev-portage, so that formal interpretation of DISTDIR would be acquired. I also adding base-system so that Gentoo interpretation of /var/cache be available. dev-portage: Can you please explain if 3rd party applications may expect to find sources at DISTDIR after merge complete? Can the user clear DISTDIR without effecting system, or it is guaranteed to contain all required sources that were downloaded by a package at all time. base-system: Can you please say if definition in comment#10 for /var/cache is not true for Gentoo distribution? Isn't the user allowed to clear /var/cache at any time and expect system to continue working? Thank you and sorry for bothering you both.
(In reply to comment #16) > dev-portage: Can you please explain if 3rd party applications may expect to > find sources at DISTDIR after merge complete? Can the user clear DISTDIR > without effecting system, or it is guaranteed to contain all required sources > that were downloaded by a package at all time. IANAPD -- but it seems to me maintaining all source for all merged packages on a system is fundamentally flawed. What happens if the user is installing most of his/her packages from binaries distributed from a build host? Do you expect source to be maintained for all SLOTted packages too, so effectively multiple versions of the source for a given package? Not to mention the fact some source is *huge* and we're dealing with users who might be running Gentoo Linux on a 32GB or 64GB SSD, or perhaps enterprise customers who've got it deployed on 36GB/73GB SAS drives? I think the Handbook is pretty clear on this, to be honest, and adding dev-portage and base-system is a waste of their time. We're all about providing complete flexibility to a user, why the hell should we do something daft like say DISTDIR cannot be cleared?
The initial bug report was not to use DISTDIR in none standard way, now after this resolved, the same issue exists in the new location (/var/cache). comment#15 and comment#17, have some conflict... Either the DISTDIR cannot be cleared and genkernel can expect sources to be available there all the time, or DISTDIR can be cleared and genkernel cannot assume sources will be available. comment#15: "I'd say valid reasons have been given by Chris for why it's handled the current way, and the Handbook (http://www.gentoo.org/doc/en/handbook/hb-portage-files.xml) seems to support this -- ..." And on comment#17 you write: "I think the Handbook is pretty clear on this, to be honest, and adding ... why the hell should we do something daft like say DISTDIR cannot be cleared?"
(In reply to comment #18) > The initial bug report was not to use DISTDIR in none standard way, now after > this resolved, the same issue exists in the new location (/var/cache). > > comment#15 and comment#17, have some conflict... Either the DISTDIR cannot be > cleared and genkernel can expect sources to be available there all the time, or > DISTDIR can be cleared and genkernel cannot assume sources will be available. But genkernel has been patched to not use DISTDIR?
(In reply to comment #14) > OK... Your call. > > devrel, please review some more examples to get better view. > bug#182065, bug#177626, bug#156431, bug#195666, bug#156445, bug#220111 (this > one). wolf31o2: You are free to give some more examples. 182065: Chris asked for root cause and a patch. Patch was provided, it worked, was commited. 177626: A patch was provided and was committed without asking. Bug sat for 3 months until it was commited by zzam. Chris mentions later that 'if zzam had asked him to commit it than he would have' but was otherwise angry that someone had committed it instead of him. My assumption there is that Chris had other plans for that code; otherwise that bug paints Chris in a bad light. 156431: Alon and Chris chat about technical issues regarding genkernel redesign. 156445: Alon and Chris disagree on technical issues. 195666: Alon and Chris disagree on a technical decision. 220111: Alon and Chris disagree on a technical decision. All I really see is aside from bug 177626 Alon and Chris disagree a lot on technical decisions related to genkernel and the liveCD, both projects for which Chris was technical lead of at the time and thus made the technical decisions for those projects. Alon, I think you need to learn to escalate, give up, or fork in these cases. It should be pretty trivial to patch genkernel in your dev overlay and provide that to users who are interested in the functionality you are offering. Software isn't always about instant gratification; 'oh adding this patch is easy' is sometimes difficult when people have plans for their software and your patch is basically orthogonal to those plans. > > devral,please also review "How we address bugs" by me from Aug 30, 2007 9:45 PM > at gentoo-core (I don't know if there is an archive). > > How a simple technical issue becomes very fast personal with no reason. > Yeah Chris tends to take comments against his work way too seriously and I think it is something he knows about and is working on. -Alec
genkernel is a Gentoo package and thus making use of DISTDIR makes a whole lot more sense than trying to create a genkernel-specific location in /var/cache which leads to large duplication of resources ... in other words, what Chris is doing sounds plenty sane to me
Eh, the distfiles thing was a bit shortsighted. If you installed genkernel from a binpkg, you wouldn't have had the distfiles.
I've updated the docs to clarify the nature of DISTDIR: --- man/make.conf.5 (revision 10288) +++ man/make.conf.5 (revision 10289) @@ -98,7 +98,11 @@ as \fI\-\-target=${CTARGET}\fR only if it is defined. .TP \fBDISTDIR\fR = \fI[path]\fR -Defines the location of your local source file repository. Note +Defines the location of your local source file repository. After packages +are built, it is safe to remove any and all files from this directory since +they will be automatically fetched on demand for a given build. If you would +like to selectively prune obsolete files from this directory, see +\fBeclean\fR(1) from the gentoolkit package. Note that locations under /usr/portage are not necessarily safe for data storage. See the \fBPORTDIR\fR documentation for more information. .br
(In reply to comment #8) > Anyway, I've committed a change that moves the distfiles to > /var/cache/genkernel/src and checks to make sure the files are there when > genkernel is run. It'll bail with an error message if they aren't. This will be > in the next _preX release. Are you sure that /var/cache is an appropriate location? Here it says "Long term data which can be regenerated": http://devmanual.gentoo.org/general-concepts/filesystem/index.html Unless genkernel will download those files on demand, does it really fit that description?
Devrel hat: I've been asked to review this issue per the request in this bug and will be talking to parties involved.
OK. This is resolved in genkernel 3.4.10, which is now in the tree and stable.
Finally fixed 2008 issue. sys-kernel/genkernel-3.4.52.2 stores files at /usr/share/genkernel/distfiles instead of at /var/cache Thanks!
