> On Wed, 3 Sep 2008 13:36:41 -0500 (CDT), Jon Ciesla wrote:
>
>>
>> > On Wed, 3 Sep 2008 12:10:13 -0500 (CDT), Jon Ciesla wrote:
>> >
>> >> > For example, why games data depend on binaries?
>> >>
>> >> So that if we try to upgrade the version of the binaries and not the
>> >> data,
>> >> it will fail.
>> >
>> > Unconvincing.
>> >
>> > Why? Because the game program pkg could require a specific version of
>> > the data pkg to achieve the same. If game version gets bumped, dep
>> > would break, since you would need to update data pkg, too. Game
>> requires
>> > compatible data. So far so good.
>> >
>> > However, if the data pkg requires the game pkg (versioned! or else it
>> > would not be strict enough for your needs), this only increases the
>> > risk that you need to bump'n'rebuild the data pkg if the game version
>> > is increased without needing any changed data. It's a superfluous
>> > dependency that only tries to enhance "yum remove" a bit.
>>
>> How? For game data, the convention is to require on name and version,
>> but
>> not release. If new data is required, it will change the version. If
>> not, we only increment the binary rpm's release, so the data rpm matches
>> on version and needs no rebuild.
>
> game-0.8 Requires game-data = 0.8
> game-data-0.8 Requires game (which version? and why?)
>
> Case 1)
> game-data-0.8 Requires game = 0.8
> What happens if game-1.0 is released with unchanged game-data?
> Then you need to update game-data for nothing else than the broken dep.
I've yet to see this happen.
> Case 2)
> game-data-0.8 Requires game
> No version. Hence no dep breakage in all cases where you may update game
> without updating game-data. Instead, a strict dependency is installed
> in pkg game: game-%{version} Requires game-data = %{SOME_version}
> Here you can control the game-data version within pkg "game".
But then if I somehow manage to update the game data but not the binary
rpm, and there's an incompatibility, Bad Things happen to the user.
>
> Dep 1) is really just for "yum remove".
>
> --
> fedora-devel-list mailing list
> fedora-devel-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
--
novus ordo absurdum
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
