It was <2013-11-22 pią 17:35>, when Kanevskiy, Alexander wrote: > 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 This won't work in a general case because, as we read here[fn:1] --8<---------------cut here---------------start------------->8--- Requires: A comma-separate list of packages that are required when the program is installed. [...] --8<---------------cut here---------------end--------------->8--- we may not have all the runtime dependencies installed in the building environment, hence we may not be able to check all the directories we create in a buildroot. However, this approach will most probably work for the filesystem. >> 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. Does it mean that a package needs to BuildRequire all packages it Requires just to detect ownership of directories? > 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. IMHO, what is most imporant is a tool to detect this kind of problems because, as Patric Ohly writes, developers who don't know all the details of the packaging system need to be able to build a proper package. We need a pach for the find-requires script or a rule for rpmlint. Otherwise we shall not know the day or the hour. >>> 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. It is also better to be safe than sorry and I'd like to have some kind of a safety net. >> [*] things === dependencies. Footnotes: [fn:1] https://fedoraproject.org/wiki/How_to_create_an_RPM_package -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgp5rghP_fsY4.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
