On Tue, Aug 25, 2009 at 09:09:55AM -0400, Michael K. Johnson wrote: > In particular, this implies that > RPM itself is fully imported, even though running RPM could > break a running system; the idea is that installing something > with rpm and overwriting Conary-managed content is really no > different than doing so with tar. That is to say, the rpm > command is on the installed system. If you choose to use > it to install packages that conflict with Conary, you broke > your system, and you get to keep both pieces. It's like tar > that way -- if you choose to use tar to unpack a tar archive > over existing files managed by Conary, you broke your system, > and you get to keep both pieces. Similarly, if you use unzip > to unpack a zip file over existing files managed by Conary, > you broke your system, and you get to keep both pieces.
there is a huge difference between tar and rpm, namely that rpm is associated as the official packaging tool for a fedora system, and people who get told that the system they are using is fedora based will expect rpm to work without breaking anything. most users knowthat using tar in the wrong place would break their system, this is documented and people asking for help will get told why their system broke in uncertain terms. with rpm however, this is documented everywhere as the correct tool to use, and people may not be able to understand the difference between a native fedora system and a conary based one. when they break their system with rpm, they will get confused because they will turn to the wrong place to help (they might ask in fedora channels, thinking they got a fedora system here, fedora users, unaware of our conary based fedora import, will try to help and fail, confusing the user even more. the only way to make it clear in uncertain terms, that this conary based fedora is not like a normal fedora anymore, is to not have an rpm binary available. there is another difference: tar can be used correctly without breaking the system, while rpm will be practically useless. so why include it? this whole fedora import will just turn into a public relations nightmare. people will be confused as to how exactly foresight is or is not based on fedora. those that do not want a fedora based system will stay away from it, and those that do want a fedora based system will expect rpm to work. i do not see any way to make the difference clear except by keping the fact that we are importing fedora a secret (or at least not make a big deal out of it) i am also concerned that a binary import of fedora will be very very dificult to reproduce in terms of GPL obligations. how exactly am i supposed to be able to replace an imported binary with one that except for my changes is otherwise identical? will i need a fedora system to rebuild the rpm on it, and then reimport that? i don't see any other way because if i build the package from source instead i will get something different alltogether (since it is now built with a different toolchain, against a different set of libraries (some rpm imports and some not) greetings, martin. -- cooperative communication with sTeam - caudium, pike, roxen and unix searching contract jobs: programming, training and administration - anywhere -- pike programmer working in china community.gotpike.org foresight developer foresightlinux.org open-steam.org unix sysadmin iaeste.(tuwien.ac|or).at caudium.org Martin Bähr http://www.iaeste.or.at/~mbaehr/ is.schon.org _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
