On Tue, Jan 28, 2014 at 04:51:49AM +0100, Martin Bähr wrote:
> On Mon, Jan 27, 2014 at 10:26:35PM -0500, Michael K. Johnson wrote:
> > With those bootstrap imports finished, we'll be able to use
> > mirrorball normally do build packages and groups. The group
> > structure will look a lot like you might have seen in the CentOS
> > import before, though instead of group-rpath-packages for the
> > Conary-related tools, we'll probably go with group-conary-packages
>
> since not all of us have seen the centos import, could you elaborate on
> this just a bit?
There are actually two sets of groups that are combined to build a
Conary-managed system.
For the encapsulated OS itself, there are:
group-os
group-packages
[all the packages]
group-standard
[normal install]
Then for the extra Conary bits, there is currently:
group-rpath-packages
group-rpath-core
group-rpath-tools
It's here that we're proposing to switch from the name of the company
that previously developed the technology to the name of the core
technology.
To explore these groups further, here are some commands:
conary rq --config 'repositoryMap centos6.rpath.com
https://updates.sas.com/conary/' group-os=centos6.rpath.com@rpath:centos-6e
--recurse | less
conary rq --config 'repositoryMap centos6.rpath.com
https://updates.sas.com/conary/'
group-rpath-packages=centos6.rpath.com@rpath:centos-6-common --recurse | less
> > Many of the problems we'll run into will be discovered after one
> > round of package importing when we are trying to build groups and
> > discover that the encapsulated packages are not conary-dep-complete.
>
> so most of the expected problems will be missing dependencies?
That's where I expect the most problems within the encapsulation
process. The fact that RHEL/CentOS 6 are the most recent OS
currently imported means that it's hard to have a sense of how
many problems we're likely to run into.
In fact, this is a good, specific argument for doing a complete
import into the bootstrap repository, and not promoting to the
permanent repository until we have dep-closed groups, because the
solution to open dependencies is to rebuild packages. That was,
I think, what we intended anyway, since the promote to the permanent
repository will be done by group... ☺
> how will these be detected? many dependencies as far as i can tell only
> show up at runtime.
By building groups. When I say missing dependencies I mean having
packages with conary Requires that are not satisfied by any conary
Provides. When we build groups, we can ask conary to calculate
dependency closure for the groups. It is normal that "image groups"
are dependency-closed.
(Aside: With GroupSetRecipe it's possible to do more things with
dependencies that we do not care about at this level, such as "add
to group A the packages from group B that satisfy dependencies not
otherwise met in group C" so if you want, you can do all sorts of
other interesting things when writing groups...)
> > After we can build groups, we'll be able to do things like import
> > updates; right now, we're sticking with the initial release of F20
> > with no updates. We really want all the initial packages in the
> > repository to make it easy to "adopt" systems that were installed
> > from the original media. Mirrorball will drive that update process.
>
> will we try to import every version of updates or just the latest ones
> available when the update runs?
No, we will import just the latest updates as of when we run the
update process. It used to be that this would leave you with systems
that couldn't be adopted, but trying to sort the updates left us
with nonsense and broken groups, and if packages got updated out
of order the wrong version would show up as newer. That caused a
lot of the extra work of the import process on an ongoing basis.
That was at the time considered important for a variety of reasons,
including the ability to "adopt" a system with any set of updates
applied. But then Conary got a feature to create "phantom" Conary
packages from what is in the local RPM database, and no one ever
(as far as I know) used the work we had been trying to build for
being able to apply individual errata separately (I don't think that
feature was ever finished anyway...) which was the other reason we
had for pulling them in.
So now we'll pull in the original base, and then start pulling in
updates with whatever mirrorball configuration Brett says will cause
us the least pain, since he ought to know since he's the one who runs
it on a daily basis...
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
