Ciaran McCreesh wrote:
> On Fri, 13 Jun 2008 10:43:39 +0200
> Luca Barbato <[EMAIL PROTECTED]> wrote:
>> Ciaran McCreesh wrote:
>> > On Thu, 12 Jun 2008 21:40:28 +0200
>> > Luca Barbato <[EMAIL PROTECTED]> wrote:
>> >>> * ordering for _pre is wrong.
>> >> hm?
>> >
>> > foo-0.26-live would become foo-0.26_pre1, which would be < 0.26.
>> > This is clearly wrong.
>>
>> No, it is correct and what you want. Upstream is aiming for 0.26,
>> once 0.26 gets in portage you want to update to the release.
>
> A lot of projects work like this:
>
> * trunk/ is current development, and is ahead of any release.
>
> * branches/0.26/ is forked from trunk/ when 0.26 is released, and is
> equal to or ahead of any 0.26 release.
>
> How does your proposal handle this?
>
>> >>> * How are you planning to handle reinstalls? Should installing
>> >>> world always reinstall live things? Never? Or what?
>> >> depends on the other ebuilds
>> >
>> > More specifically?
>>
>> the live ebuild act as template for a autogenerated _pre, if there is
>> something higher than _pre that one will be picked.
>
> So you install foo-1.2-live. The package manager installs this as
> foo-1.2_pre1. Then, foo-1.2-live becomes foo-1.2_pre2.
>
> Which has two issues:
>
> * It means whenever you install foo-1.2-live, there will always be a
> newer version, and the package manager will always select it for
> upgrades. Is this really desired behaviour?
>
> * It means the package manager somehow has to keep track of what pre to
> substitute in. How does it do this?
@lu_zero: I don't think we can get away without having the pm know what a
live-ebuild exactly is and when to re-install it.
(Just in case you were thinking of letting the pm auto-masking/unmasking
foo_p${value+1}: this would be hackish and ugly).
--
[email protected] mailing list
