Brock Pytlik wrote:
> >However, here's a scenario:
> >
> > - publish FCS package: [email protected]
> >
> > - publish SRU package: [email protected]
> >
> > - publish update package: [email protected]
> >
> >The update package would need to be compared to the FCS package, since the
> >SRU package represents a divergent branch. I don't think there's any way
> >to determine that automatically, though, meaning that you need to tell the
> >publication tools specifically that the FCS versions are the ones you want
> >to look at.
>
> I'm not sure I agree with that. I would think [email protected] sould be compared
> against [email protected], assuming that they're all ending up in the same repository.
> To extend the comparison further, I'd also say that 1.2.0 should be compared
> against 1.1.10 (assuming that had been published by the time 1.2.0 came
> along), not 1.1.0 nor 1.0.0. I don't see why you'd compare against [email protected].
> The one reason I could see is that since we have separate repositories for
> support/dev/release, we want all package versions published in release to
> appear in support. To use the example above, because we published [email protected] to
> release, we want [email protected] to appear in support, even if it's identical to
> [email protected]. Is that the thinking behind the example provided?
No. The thinking is that packages evolve divergently along each branch of
version space, and that you don't want to perform comparisons across
branches, only against the ancestor of the version you're currently
publishing. Since there's no way to tell automatically whether the series
1.0.0, 1.0.1, 1.1.0 represents a line:
1.0.0 ---- 1.0.1 ---- 1.1.0
or a tree:
/---- 1.0.1
1.0.0
\--------------- 1.1.0
then you have to tell the system explicitly that 1.0.0 is 1.1.0's ancestor.
The incorporation i constraining the functional packages is the one with
the version numbers we're talking about here, and the functional packages
p, q, etc, have the same version if they've changed, otherwise they have
the latest version in which they've changed.
Say that a package p incorporated by [email protected] has taken a security fix, so
it shows up in the repo first (out of order putback). The corresponding
fix isn't ready for 1.1.0 (it'll have to wait until 1.1.0.1). Other
changes have gone into the consolidation (say we need a [email protected]), so we
produce an [email protected] which incorporates [email protected] and [email protected], not @1.0.1.
> Well, imagine that a@2 removed functionality present in a@1, and a@3
> restores said functionality.
Then we've violated one of the basic premises of the packaging system,
which is that if a@v satisfies a dependency, then so does a@v' for all v' >
v. Do we want to support broken packages like that?
> Sounds good to me. All I've been trying to say is that if we don't have a
> lock, we need to be clear about what we do and don't support and we should
> communicate those restrictions clearly to users.
Okay. That's easy to agree on. :)
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
