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?

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.

> 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.

[*] things === dependencies.

Kind regards,
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

Attachment: pgplk1w9DEtMR.pgp
Description: PGP signature

_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Reply via email to