[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: rpm: can it comply debian policy?



> 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 debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: