Andreas Jellinghaus <aj@dungeon.inka.de> writes:
> > Please tell me where I am wrong.
>
> your create complexity where there is none.
> source handling works very fine for me, and i simply do not understand
> why you add this complexity, like managing sources as root.
1) I see much less complexity:
- only one file format (.deb) vs. many (.deb, .dsc, .tar.gz,
.diff.gz)
- same delivery mechanism, one indexing mechanism (Packages)
(key advantage: as this improves, our source distribution
mechanism would improve as well)
- same dependency mechanism
- same control file format
2) I have demonstrated that you have 2 options for managing sources
as a user:
- extract .deb files manually using dpkg-deb --extract (or
using ar, tar and gzip) - essentially the same thing as
what dpkg-source does
- install and use dpkg in user space (benefit: can be used to
manage dependencies)
Granted, managing sources is a much simpler job than managing binaries.
But that's was the beauty of my proposal, dpkg already provided a
strict superset of the required capabilities - so it could be
"reused" with no additional code. In fact, dpkg-source (which
currently does not provide all the required capabilities) would
not be needed at all.
Perhaps I should have called it "unified" source and binary package
management.
> i only see the disadvantages.
>
> so : please not show me example code, please show me and explain the
> advantages you have with this method. then i can either show you, that
> we can get these advantages much easier, or i will step back and say
> "hey, there are advantages i did not know, and it's the only way we can
> get them."
Some ideas I had that require consistent (and preferably unified) handling
of sources:
1) Instant debugging.
Normally, you wouldn't have binaries with debugging symbols loaded
on your machine. But when you ran into a problem, you could just
load the source package, and another package containing binaries
with debugging symbols - and plug away. This would all be handled
virtually transparently by the packaging system. (Sure you could
do this with dpkg-source to, but it would require much more code)
2) Linux kernels & patches
We already distribute the kernel sources in a Debian package (just
as I proposed doing for all sources). We could also distribute
sources for patches from LinuxHQ in packages. And then Manoj's
kernel-package package would just use the same standard mechanisms
I proposed to build the package.
3) "Pseudo-Packages"
You could locally create a "pseudo-package" that consists of just
sources. When you install it, dpkg (or a front-end on top of
dpkg) would compile it from scratch. A pseudo-package might just
consist of a patch you need locally. It would just declare a
dependency against a real Debian source package. The complex
dpkg dependency mechanism will come in really handy when you try
to do fancy things such as create a custom Linux kernel which
depends on the kernel source, the standard Debian modifications,
patches from LinuxHQ, the SoundBlaster AWE32 driver, and a few
local modifications. The nice thing about "pseudo-packages"
would be that upgrading any dependencies would result in a
recompile with little work on the part of the user. Of course
there would need to also be an error handling mechanism in place
for when building a package fails.
Think of this as a modular, distributed make world process. Instead
of having the dependencies in a static file (as in make), they are
dynamically built from the source package control files.
4) Documentation
Documentation comes in many forms - too many. We need mechanisms
to dynamically generate it from source. A system administrator
can just create "pseudo-packages" that act on the source for
packages to dynamically generate documentation in the form they
want (ie. PS docs on funny paper sizes, HTML-only, GNU info-only),
etc.
5) As a meta-data distribution mechanism
With the advent of XML, there is going to be an explosion in the
use of "meta-data" and it is going to need a distribution
mechanism. Meta-data is just another way of saying "raw relational
database data". But it is typically stored in an ASCII format
that is easily portable, and is typically processed to place it
in other databases for querying purposes. The Linux Software
Map (LSM) is a fine example of meta-data in action. The
Debian Packages and control files also fall into this category.
This type of data (particularily XML) is likely to gain wide
popularity in vertical industry markets. This type of data,
when widely distributed, provides another mechanism for competitors
(and communities) to share information.
In essence, meta-data is source code. The use of dependencies and
automated build mechanisms (ie. pseudo-packages or makefiles) are
essential for efficient handling of this stuff.
> if i make changes in source with several revisions, it is a very nice
> feature, that i only have to transfer diff files. that does not work
> with binaries, but with source, and this is why we have a package format
> (ar) for binaries, but several files for source.
Look at my proposal again, it does have that feature. (I feel like
a broken record)
> please write down your arguments, (best : as a sgml document - we will
> have the same discussion in 3 months).
Yes, I think I will do that. Particularily since I need these
capabilities for some of the things I plan. But I plan on removing
all references to dpkg and Debian - as these only serve to complicate
the message.
Cheers,
- Jim
Attachment:
pgplAB6JAxtXs.pgp
Description: PGP signature