> It may work, that's true. But I think it's completely bizarre for a > package to contain ownership information that isn't intended to be > preserved.
Agreed. But rpm is not designed to operate in conjunction with dpkg. The two programs are written in isolation. There is no interaction between those two. rpm by itself operates just fine. dpkg by itself operates just fine. They don't operate the same as each other. > If rpm doesn't preserve ownerships at all, then I think that is a > design flaw (principle of least astonishment). When did anyone say that rpm did not preserve ownership data? I did not read that anywhere. I said that *alien* did not preserve ownership when converting rpms to debs. rpm preservers ownship fine. As someone that has extensively used rpm and created hundreds of rpm packages myself (mostly repackaging for hpux) I will say that rpm does a fine job of preserving ownership. > If it [rpm] does preserve ownerships in the general case and just > converts ownerships it doesn't know about to "root", It is true that rpm does that. But why are we talking about it and how does that apply to the discussion of alien not preserving rpm ownership? I don't follow how it is related. > then I think it's clearly a latent bug in the package What would you have it do? Preserve the number id even though the number id does not exist on the current system? That would certainly be possible. But others would just as strongly dislike that as much as you seem to dislike converting it to user id 0. Whatever course of action is taken some will dislike it and it really does not matter because you should *not* be installing files as unknown users! Just don't do it and you won't have to worry about what behavior should happen if you do. Don't do it! lintian would object and if something like lintian were available for rpm then it would object there too. (Lintian is a good thing. So much of what makes Debian a good thing is embedded in the policy and not so much in the tools.) > (what happens if you happen to have a user whose username coincides > with the person who built the package? Do all the files end up owned > by that user?). Huh? Of course not! I think you are fishing for trouble here. I am really trying not to have this discussion turn into a bashing of either rpms or debs. Please don't start up a baseless bashing session. Let's say that me, 'bob', creates a BIND rpm package where I want the files owned by a non-root user 'named'. I create the package as 'bob' and you install it as root. The package says the files should be owned by 'named' as I indicated when I created the package and since you install it as root, rpm will be able to set the ownership to 'named' as I specified in the package. The same would be true if I wanted to set the ownership to any arbitrary user or group. (And this is not a real example, I would not really have the files for a bind package owned by named, I just could not think of anything better.) In rpm there is no relationship between who creates the package and the ownership of files in the package. That is a Debian thing which I consider a limitation. I know why it is there and it is okay. But it is why fakeroot is needed. An extra complication required because the packaging is simpler. The balance is maintained. I recommend that you operate as little as possible as the superuser. Therefore I always create packages as a non-root user. It is safer in case you make a mistake. No 'rm -rf /$var' where $var is unset can get away from you and destroy your build machine when you are trying to debug a makefile or a script. Operating as root all of the time takes away any safety net whatsoever. This is what fakeroot helps with. rpm does not need that concept. > The technology to avoid this whole can of worms is there in the form of > fakeroot. Given Debian's mode of operation fakeroot is a good thing. > That's not to say that alien shouldn't try to duplicate the can of > worms where possible, but the packages you're describing aren't ones > to which I'd ever want to put my name. Just because they are .rpms does not make them evil. A lot of high quality work is available and it is frequently a huge timesaver to avoid recreating them. Just recently a Synopsys package needed shared libs from libncurses4 which Debian does not support. I could not find a debian version anywhere. Perhaps one exists but I could not find one. I did an alien conversion of an rpm package and was up and running in minutes. dpkg knows about all of the files and everything is good to go. It is a beautiful thing. > One query: does the conversion process work if you ensure that all the > usernames embedded in the .rpm exist on your system before starting the > conversion? That is the normal case for me and no, alien does not convert those properly. I think if the user names were not known that it might convert them to root inadvertantly which may be the right thing to do and it would cover up for not doing in the case that the user id is known. If you go here: http://www.kitenet.net/~joey/pkg-comp/ I think you will find that ownership data referred to as metadata. The discussion goes that rpm makes it more difficult to get to the metadata than alien would like it to be. I agree. But that doesn't make it a bug. Because it is difficult alien does not completely translate it. (Yet.) This is not a bug in alien either. It just is. Deal with it. Bob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
