Hi, On Fri, Mar 28, 2008 at 01:36:54PM +0530, Praveen A wrote:
> AFAIT mbank was referring to names that distro packagers give, which > changes for each distros. The files itself won't change, only that the > exact package might defer. For example debian's pango package name is > 'libpango1.0-0' where as it is just 'pango' for fedora. Also how the > package is split is also differ between distros. The individual > filenames is fixed by upstream projects and does not vary from distro > to distro. That's simply not true. Sometimes files are renamed in the distributions. More often, the contents differs -- incompatible versions, different compilation options, custom patches etc. You just can't assume that a file from one distribution will work with packages from another. You do not seem to realize how hairy these things are. Maybe you should spend a couple of hours reading Debian changelogs or something. I take *any* bet, that mixing packages from different distributions *can't* *ever* work reliably, period. Sorry for being harsh, but the fact alone that you believe it possible proves that you don't really understand what you are trying to do here. It's hard enough to achieve consistency even within a single distribution! Running packages not specially tailored for the Distribution can work under narrow conditions: With pure application programs that don't touch system internals; using specially prepared packages without external dependencies beside some base set. That's what LSB packages are for. In any other situation, it just won't work. I don't quite see the use in mix-and-matching packages from various distributions anyways. Every major distribution comes with a comprehensive set of packages. Settling on a single distribution (most likely Debian) would make this project way more interesting... In fact, we already have been pondering this -- it would be extremely valuable if we could use all the good work done by Debian. But even that is problematic. It will most likely work for simple cases, where there are no conflicts and no postinstall scripts. But what to do about the other cases? Executing the postinstall scripts is out of the question -- it would totally break the stateless package management approach we want to have in the GNU system. Without the scripts, many packages won't work properly... A trivial approach that only unpacks the files and ignores any scripts might still be helpful in some cases; but that's way to simple for a GSoC project. It would be interesting though to try to find a middle ground: Identify common postinstall actions (updating menus, info directory, alternatives etc.), and exposing the information contained therein in a form useful for stateless handling. If someone could come up with a *convincing* application for such a project, that would have good chances of getting accepted. (The UPM application handed in by Ajish.B is not convincing at all -- it's *way* to vague to be considered...) -antrik- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
