On 22/11/13 17:44 , "Łukasz Stelmach" <[email protected]> wrote:
>It was <2013-11-22 pią 15:11>, when Kanevskiy, Alexander wrote: >> On 22/11/13 16:01 , "Łukasz Stelmach" <[email protected]> wrote: >> >>>It was <2013-11-22 pią 13:34>, when Kanevskiy, Alexander wrote: >>>> On 22/11/13 11:07 , "Łukasz Stelmach" <[email protected]> wrote: >>>> >>>>>It was <2013-11-22 pią 06:42>, when Dong, Junfeng wrote: >>>>> >>>>>> I submitted the change of "Removed prepackages section of RD-PQ" >>>>> >>>>>My investigation led me to a conclusion that we need the %prepackages >>>>>section containing setup and filesystem packages. >>>>> >>>>>https://review.tizen.org/gerrit/12480 >>>> >>>> what exactly require packages to be installed with ignoring >>>> dependencies ? >>> >>>It is the way the dependency solver works. If a package without >>>dependencies (or with very weak ones) appears like boost-license, >>>terminfo-hwbase or hwdata we can't guaratee it won't be installed before >>>the setup and filesystem packages although it MUST NOT. Fortunately, >>>now, neither of the three packages has any files in /bin, /sbin, /lib or >>>other directories provided as symbolic links by the filesystem package. >>> >>> >>> If a package with a file in one of these directories is installed >>> BEFORE the filesystem package, the directory won't be symlinked and >>> an image ends up with separate /bin and /usr/bin, /sbin and >>> /usr/sbin and so on. >> >> >> this is clearly a bug in those packages that are lacking dependencies >>that >> needs to be exposed and fixed. > > >The problem is, there seem to be no way to detect such bugs before we >can't build an image. I'd rather he's got his packge explode him in the >face than break the image. > >In general: nonexistent things[*] are hard to find. > >>>To prevent this from happening we can: >>> >>>1. Make all pacakge maintainers aware of the problem and hope they will >>>add dependency on the filesystem package if they provide anything in >>>/bin. (IMHO this is the least reliable solution). >> >> IMO, this is the best way. it should be explicit hierarchy of >>dependencies >> between packages. >> If package provides some file in directory hierarchy that this package >> doesn’t own (e.g. */bin), then it should be dependencies to components >> that provides those directories. > >How can you tell that a package owns, or not, a directory? rpm -qf /some/file/or/directory > >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. > >> Implicit dependency declaration (like in debbootstrap) is just a way to >> hide problem, not to solve them. > >I agree this does not look very clean, yet it works for Debian well >enough to consider it an option. IMHO. "Explicit is better than implicit”, one of the mottos for good programming practices. > >[*] things === dependencies. -- Best regards, Alexander Kanevskiy. --------------------------------------------------------------------- Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
