On Thu, Jan 30, 2014 at 07:52:38AM +0100, Mark Trompell wrote:
> What we do is creating some labels on fl3.flnx.org like
> fl3.flnx.org@fl:3p <- for packages not in the label above (or packages
> we want to replace, we might want to have qa/devel label here too, not
> sure)
> fl3.flnx.org@fl:3g{,-qa,-devel} <- to put our groups there. building
> and testing them and if they're good enough we promote them (only
> groups, no packages) to the 'better' label
Let's discuss the names for those labels separately. But yes,
I've suggested in the past that we keep the packages and groups
separate and promote only the groups. Much faster!
And system model is what makes that work; when you consume packages
by groups, you don't have to manage access to packages by label.
> the groups on fl:3g define our system. They define which package we
> get from which label. So even if we update to f21.flnx.org we would
> actually not change our search line in system-model, as long as we
> don't change to fl4.
Exactly. And when changing fl3 to consume f21, you might have to
attach group scripts that deal with upstream changes to make things
work, since upgrading from release is one of the difficulties in the
fedora universe. Conary groups ought to really help there.
> In the short term, especially for us devs, we would have an adopted
> system before our groups are in place, so we would search on
> f20.flnx.org.
That's where you start before anything exists on fl3, yes.
> One thing I'm not sure about. How would we replace a package like
> libfoo. If we do, we won't have libfoo:rpm anymore but
> libfoo:{lib,devel,devellib}. So for binaries it wouldn't be that
> important I guess as conary fill find out that libfoo.so.1 is now in
> libfoo:lib and not libfoo:rpm so package needfoo will get its
> dependancy provided.
> But if we earlier decided that we can do a better needfoo than fedora
> does. We need to double check buildrequires. because needfoo has
> libfoo:rpm and might get trouble rebuilding when we later on provider
> our own libfoo and libfoo:rpm isn't available in our groups anymore
> (but may still in our search paths).
You can't reach into the middle of the RPM dependency forest
and just replace an RPM with a Conary native package, because it
will not satisfy the rpm: dependencies that are discovered from
encapsulated RPMs. On an encapsulated platform, the encapsulated
RPMs have to be the core, on which native Conary packages can depend,
but there is definitely a technological layer there.
Basically, all the rpm: requires in the conary packages that
encapsulate RPMs need to be satisfied by rpm: provides in those
conary packages. And the only way to get rpm: provides and requires
is to encapsulate an RPM, one way or another.
So, you have a choice:
* Replace libfoo with a Conary native package, and replace EVERY
encapsulated package that depends on libfoo with a Conary native
package as well.
* Replace libfoo with an RPM sourced from somewhere else; say,
pulling in libfoo from rawhide and adding the encapsulated
package to fl3.
* Use Conary to call rpmbuild to build an RPM from source and
encapsulate the output of that build.
* Use Conary to build an empty libfoo RPM as part of building a
native conary libfoo package, and make the libfoo:rpm component
depend on the libfoo:lib component in that package.
That last idea is one that I hadn't thought of before, and probably
has the most flexibility, but would be some work to implement, and
I'm not volunteering at this point... ☺ But there are at least
several technically possible options to consider.
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
