On Fr, 2013-11-22 at 16:35 +0000, Kanevskiy, Alexander wrote: > On 22/11/13 17:44 , "Łukasz Stelmach" <[email protected]> wrote: > > >Please remember, that whatever you propose, it needs to be fool-proof > >and backward compatible, which means we shouldn't have to touch any spec > >files we've got today to add the depenencies. > > > I wasn’t able to find that in few minutes, but I remember quite long time > ago it was in rpm guidelines section about > installing files in directories that are not created by that package. > Current packaging guidelines e.g. in Fedora have a bit relaxed description > of that problem: > http://fedoraproject.org/wiki/Packaging:UnownedDirectories > > -8<- > The term "unowned directory" (or "orphaned directory") refers to a > packaging mistake where these three things happen: > > * none of the package's dependencies provide the directory either > -8<- > > > so, in this scenario, if we have package that has 0 dependencies, but > still tries to install files into directory that it does not ship with > itself > (e.g. there is %{_libdir}/something/somefile, but there is no %dir > %{_libdir}/something) it should be dependency to package that brings that > directory into the system. > > When Tizen 3.0 work was started earlier this year, all cases with > unpredictable dependencies were cleaned-up and the need of prepackages > from images was avoided. > > If after mass syncing 2.2.x code into 3.0 codeline we got again into the > stage where unpredictable dependencies on files exists - those are bugs > and _needed_ to be fixed in the spec files that are introducing problems.
It's all nice and well to demand better packaging... but remember that in Tizen, mere mortal, normal developers are expected to do packaging. Not all of them are distro engineers like you who know these rules. A single person can't be an expert in everything. Even if it is not the right technical solution, I'm with Łukas here: better have something that is a bit more tolerant of packaging mistakes, because they will continue to happen. Or ensure that it breaks immediately and in a way that prevents including a broken package in the distro in the first place. For example, a brute-force approach would be to try to install each .rpm on a clean system automatically. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
