On 04/19/12 13:28, Danek Duvall wrote:
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.
I was following along up till the last sentence. Why would you
incorporate against 1.0.0 when you know it has a security bug in it? Why
wouldn't [email protected] incorporate against [email protected] and [email protected]. Then when the
fix is ready for [email protected] (I guess I would've expected this to be 1.1.1
but whatever), a new i would come out, lets' say [email protected] which
incorporates [email protected] and [email protected]?
I guess I'm having trouble understanding how the "tree" ever actually
exists... As far as I knew, our packages always represented a line since
that's how the solver regards them. You can use incorporations (or
optional or versioned require dependencies) to select certain regions of
said line, but I fail to understand how a tree as you've drawn above
actually exists. As you mention below, if we publisher [email protected], [email protected],
and [email protected], [email protected] is supposed to be preferred over [email protected] unless
something else holds it back.
I guess the thing I'm still not understanding (and I really am trying to
grasp what you're telling me) is why, even if you say the packages are a
tree and not a line, why you would want to compare [email protected] against
[email protected], when [email protected] exists and is available.
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?
That's fair. I think we have accidentally done things like this but I
don't have examples at my fingertips at the moment, and I suspect
customers will as well, but I'm ok with saying "don't do 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. :)
Cool :)
Brock
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
