On Fri, May 29, 1998 at 08:18:15AM -0500, Stephen Carpenter wrote: > I have been reading the threads talking about the "LSB" and its possible > "endoresment" of RPM format. Some of this discussion has lead me to think > a little more about our own dpkg and the problems of multiple > distributions using the same package format (ie the idea of an SuSE user > downloading RedHat sysvinit and figureing that an RPM is an RPM and > installing it) IMO, LSB should NOT endorse a single package format. It would be reasonable to release rpm and deb packages, but it should include neither. > The problem here (as someon else stated) is that when multiple dists use > the same package format it only gives a "false sense of compatibility". My > thought is that a package managment system needs to take this into > account. That's why it should not include a package system. => What is needed for compatibility between dists is first to put files in the same places (FHS), to call packages the same things (cooperation between dists), and some sort of API for handling things like init scripts and the like. At least FHS and some of the API stuff is already a goal afaik. That will make .deb more universal than .rpm is currently and alien will be able to translate .deb into other formats more easily. If redhat does similar, applications should be easier to convert formats. All that would remain is dependancy info since the two package formats. If we can solve that, not only would apt be a universal package manager working with either .deb or .rpm files, it would be able to use both on the same system. Is it likely to happen? Prolly not. But hey, can you blame me for hoping it can? In the end, all Linux users are in this together. Different dists just represent different philosiphies. > AFAIK no such field currently exists in the deb format (if I am wrong then > I am sure I will be told) so I would propose the addition of a > "distribution" field in the control file. .deb files have a standards-version field. This field contains the version of policy the .deb was designed for. I do not know how it is used, but any package which fits Debian policy well enough at least will install fine on Debian. Any debian-derived dists which use dpkg the debian package policy as to where files go and the like will be interchangable. > My thought is this...if in the future some other distribution decides to > use the deb format (I kno wthis seems unlikely right now but it could > happen) then they woul dput the name of their dist in that feild. dpkg > could check this against a dist name that is part of the base system (or > possibly should be contained in dpkg itself) I'd really rather see policy become more in line with standards. "debianizing" a package is NOT just adding a debian/* file set usually. I'd much rather see the term "debianizing" be replaced with "standardizing". For that to happen, our policy needs to say to do things essentially the way the majority of others are doing it. Right now, we don't even use the FHS. In slink this will start to change. > If this field does not match then dpkg should warn the user that this deb > is not made for the debian system and may not follow debian policies, thus > it may break other programs. It should then prompt about whether or not to > continue. > > replacement of any package with a priority greater than "optional" (maybe > standard) should require a --force- addition. > > I know this is probably not needed in many cases...since they might choose > different package names from us, and thus it should fail if it has any > dependancies which have differnet names, but we shouldnt rely on that. With the right things in policy, this shouldn't be needed IMO. I'd really like to see Redhat at least suggest a policy similar to Debian's for packages to keep them compatible. > Am I making sense here? I really doubt this would be hard to add...and > IMHO I think this would make deb a format much more friendly to use in > other dists. Of course this would have to be an optional field for a while > since existing debs don't yto my knolwdge have it, but eventually I think > dpkg should get to the point (after it has had time to work its way into > every package) where dpkg should warn even if it doesn't exist It wouldn't be hard to add, I just think that we shouldn't. This is a small workaround to a big problem. The problem isn't so big, other than that we can't get people to agree it needs to be solved. Fixing the problem is harder, but better in the long run. There are a lot of users out there who need the problem fixed, not patched. And besides, compatibility between dists makes us just a little more attractive to the hopefully soon to be ex-M$ users.. > any thoughts? Yes I know this probably isn't really a high priority concern > but..its just a thought. Whelp, there are a lot of people starting to rethink the entire layout of the dist now, including myself. If Debian is going to rethink a major portion of the way its internals work, it may as well start thinking the right direction. I value your opinions because they made me stop to think about and refine my own. > PS I wont be able to read any replys to this after 1pm EST today as I am > going away for the weekend, I will be back tuesday night I hope Look forward to hearing your thoughts Monday.
Attachment:
pgp1t6UTkOjh8.pgp
Description: PGP signature