Re: Participation in Google SoC
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-
Reply to: