hi,
ermo and mkj had a nice conversation on irc yesterday about the import process
i thought it would be worth to share this here, so i reformatted it for easier
reading:
(unfortunately, while editing, i managed to delete my foresight irc-log for
this month. does anyone else keep a log? there could be more gems especially
this month)
this text is edited minimally for obvious typos and has linebreaks added.
mkj: what we're doing now is building "encapsulated" packages where RPM is
used to do the install of the RPM packages on the system
ermo: what does conary manage/add then?
ermo is trying hard to understand the bigger picture
is conary just a 'front-end' replacment of yum in a sense in the
encapsulation scenario?
i.e. if I want to update my "adopted" f20, I do a conary updateall
instead of a yum upgrade?
and then conary interfaces with the rpmdb and does its thing?
(apologies if I'm being a bit slow on the uptake here)
ermo goes over the posts in fl-devel
mkj: so, foo-1.rpm is imported into foo:rpm which contains the RPM but has
conary metadata (including deep dependencies) wrapped around it. the
foo:rpm
component is then included in groups.
so you can manage your system using groups
but when conary installs foo:rpm, it hands the rpm off to librpm and
tells it to install it
so conary is not merely a front end replacement for yum in this context;
it keeps you at consistent slices of the OS, using a system model
ermo: mkj: so 1) I use conary exclusively to manage my fedora install and no
longer touch yum and rpm and 2) I gain most of the advantages of conary,
except
that any fedora packages I want to change aren't .recipes
mkj: at least many of the advantages of conary
ermo: i.e., I need to change the SRPM .spec file instead
mkj: so, conary can also manage native conary packages on top of the managed
RPMs
but native packages can't fill rpm: dependencies
so you can't replace random components
or, rather, to replace things that are inside the OS you have to build
rpms
it would be possible to build that kind of automation into the conary
build side, but we haven't worked on that so far
we had to do that (by hand) to import the packages, because the
filesystem rpm has permissions that break the chroot, so we had to run
the import process using a modified version of the filesystem rpm that we
imported on the label that has the conary tools
ermo: mkj: well, it also depends on where you want conary to go, I presume
the 'filesystem rpm' <- is that a filesystem.rpm package?
mkj: yes
we had to build it with a patch to the spec file to change the permissions
ermo: ah, ok
mkj: because the "root" user in the chroot isn't actually root
so directories like / having non-writeable permissions broke the rest of
the install process...
ermo: in your personal opinion, is it "worth it" to teach conary to build
conary-installable RPMs from .recipes?
mkj: that's one of those things where we had to make a change for the import
that fedora probably woudln't consider their bug...
yes
groups
sooo much easier to manage
if I didn't think it were worth it I wouldn't have been working on it!
ermo: oh, where a conary .recipe describes a group of (conary encapsulated)
RPMs and this conary .recipe is translated into a RPM?
mkj: no
conary is on the managed
system
conary is on the system, as a native conary package that it manages
then we have a few groups
we have a group that is JUST Fedora 20
we rebuild that group every time we pull in new updates
it represents slices in time of F20
we have another group of conary and friends (rmake etc.) built for F20
then you have a system model that searches those two groups, installs
various groups that you want from F20, and installs conary and whatever
"friends" you want
that's conary-managed F20
ermo: we're talking slightly past each other (even though the info you're
spoon-feeding me is good)
mkj: now, those who want to work on fl:3 can build a group that references
only the pieces of F20 that they want, and includes any native conary
packages they want, including conary
that's separate work
ermo: I think my question was about defining a f20 'spin' comprised of RPM
packages
mkj: now, we have conary source packages for RPMs to import. we have one such
source package for each srpm
ermo: from within conary groups
mkj: as an implementation detail, they don't contain .recipe files; they just
use a common factory instead
(I'm still working toward your question...)
ermo hits pause on the info-stream to ask a question
so the 'encapsulation' is not an SRPM rebuild?
mkj: correct
we include the SRPM in the :source in order to have it and be sure we
comply with the GPL about shipping source code with binaries
ermo: but you said "now, we have conary source packages for RPMs to import. we
have one such source package for each srpm"
mkj: but it is inspecting and wrapping up all the RPMs as provided by Fedora,
not rebuilding them
ermo: ... ah, ok.
now I get it
the SRPM is not the 'source' per se, but rather a 'supplement'?
mkj: so the :source component contains the srpm and rpms, and then generates
binary :rpm components, one for each :rpm
it's just an artifact
we check it in and don't do anything with it
ermo: roger
mkj: which gets to my other point, that we *could* add capability to call
rpmbuild to build rpms from srpms, but that's additional work that hasn't
been done and isn't on my radar anywhere
ermo: (and it actually sounds rather clever, if a bit storage-consuming)
mkj: well, the RPMs are the majority of the content, and they are stored only
once
they have the same content whether they are in the :source or :rpm
package, so they are stored only once in the repository
unlike yum repositories, where the 32-bit packages are included in both
the 32-bit and 64-bit directories separately
ermo: aha
another good point
mkj: that's one of the nice things about content-addressable storage
ermo: so we basically 'leech' fedora build-cluster power and then wrap the
artifacts up in a nicer, slimmer package while offering better
metadata/dep resolution and group logic?
(because we don't actually build any RPMs ourselves)
mkj: slimmer only in the sense that a full conary repository should be smaller
than a full yum repository
the dependencies are much larger, though, since conary finds lots more
dependencies that rpm does
ermo: well, the extra dependencies found are not a liability but rather a value
add
mkj: only addressing "slimmer" here
they *do* make update operations slower
ermo: well, if they're more 'correct
mkj: if your dependency graph is two orders of magnitude larger, it simply
takes more time to resolve it...
ermo: ', that sounds like a wortwhile trade-off.
mkj: they might argue that "good enough is good enough" and in fact we made
that assumption and are cutting out many of the dependencies that conary
generates, but leaving the provides in order to build native conary
packages on top of that base
it's going to be interesting to see whether we have piles of dependencies
not satisfied when we build the last few packages and try to build groups
ermo: possibly a stupid question, but: is it possible to primarily consume
SRPMs (instead of primarily consuming RPMs and using SRPMs for compliance
and meta-data) and generate native conary packages from conary
(factory-based) .recipes?
in other words: when you decided to encapsulate, what made you decide to
do that as opposed to working directly on automagic translation of
SRPMs -> conary native packages?
Is the latter what meeuw tried?
(for a small subset of the fedora 20 base)?
thanks, mkj and ermo!
greetings, martin.
--
eKita - the online platform for your entire academic life
hackerspace beijing - http://qike.info
--
chief engineer eKita.co
pike programmer pike.lysator.liu.se caudium.net societyserver.org
BLUG secretary beijinglug.org
foresight developer foresightlinux.org realss.com
unix sysadmin
Martin Bähr working in china http://societyserver.org/mbaehr/
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
