On 11/21/2013 05:57, Martin Bähr wrote:
On Thu, Nov 21, 2013 at 11:23:02AM +0100, Mark Trompell wrote:
I'll try to keep this discussion going, will you be able to minimally
help out and explain what you did (how and why),
Actually I would like to have things rebuild from ground but let's
face it until we don't have more people fluent in that lowlevel stuff
We should just go for binary or srpm import of a sane fedora base and
keep options open to go to more independance step by step if we want
and more devs pop in (if that happens at all)
We need to quickly line out a way to get to f3 and then having people
comitting time in doing the tasks.
so what are the next steps?
where are the holdups?
can we temporarily fork conary to get the patches needed to import
fedora? are those patches enough, or are there more issues?
does that import then produce a runnable system?
what else is needed to be able to migrate from fl:2?
is that an issue only with supporting updateall and
shouldn't "conary migrate" work in any case?
or is even "conary migrate" problematic?
Migrate can't do anything updateall can't do, it's just choosing which
troves should be installed. After that it's the same install code no
matter what mode it's in.
There are two solutions that can address the problem at build time:
1) Don't allow packages to install into /bin, /sbin, or any other
usrmerge symlink. I like this one, because it produces the best
packages. But it might not be expedient because a custom policy might be
needed to fix it. The policy would be useful for both the distro import
as well as for new packages built later.
2) Automatically add a requirement on the filesystem trove to any file
installed into the usermerge symlinks and let the dep solver order
things correctly. Unfortunately it will not guarantee that such troves
will be installed strictly after the filesystem trove: it might happen
in the same job. I don't know what will happen in that case. This option
is easy to do, just add some Requires lines to the distro policy.
Neither of these will enable the use of previously-built packages. I
don't think there's really a good answer to that, but it should probably
be addressed. However if the distro itself is sane then most people will
never run into problems, they only come up when packages installing into
a symlink are in the same install job as the symlink itself, and "extra"
packages typically aren't a problem because they get installed later.
There is an option available for rmake to force a particular trove to be
installed first, called "bootstrapTroves", that was added for SLES. But
it is inelegant and doesn't help migrations.
Coincidentally, I attempted to do a "yum upgrade" from F16 to F19 just
this past week and it exploded for the same reason -- stuff in the way
of the usrmerge symlinks. There are still a good number of packages that
are installing into /bin, most annoyingly including rpm itself.
Regardless of whether it's RPM or Conary, installing managed files into
a symlink is really not a good idea.
Joke option #3: use bind-mounts instead of symlinks. Confusing but
effective!
_______________________________________________
Foresight-devel mailing list
[email protected]
https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
