Re: Debian (and RedHat) source package format (was Re: Qt and other)
Wichert Akkerman <wakkerma@cs.leidenuniv.nl> wrote:
> Kernel modules, like the PCMCIA and ALSA packages. checker, probably
> others as well.
We already have kernel-source as a package (actually, a set of packages,
one for each supported kernel version). Supporting checker using our
current packaging model would require a (set of) gcc-source package(s)
as well. But probably is worth thinking about supporting a source
package system which is as mature as our binary package system.
To support generic source packages as transparently as binary packages,
we'll need to review the .dsc file format and make sure that all
relevant headers are required. Then we'd need to upgrade master
(currently, the "source" directories don't get Packages files). Also,
a convention would have to be devised to properly distinguish source
packages in dependencies, and apt would have to be upgraded to support
these mechanisms (so would dpkg -- if only to not break when encountering
such dependencies).
One advantage of source packages over binary packages: you can have
different versions unpacked at the same time. This is also a potential
source of confusion unless we define a good set of rules for when it's
ok to toss a source package. [There's already been some discussion of
this issue for binary packages which use Replace:/Conflicts:.]
Another advantage of source packages is flexibility -- if someone wants
to turn on debugging, have executables statically linked, use pine,
use pgcc optimized for pentium pro, etc., source packages will (at
least in principle) tackle those areas. But to support this we need
to think about the association between the control file and the source
package -- most of what we need can be achieved simply by looking at the
Packages file for some set of binaries [for example: binary-i386] and
using that as a model. However, that we'd need to provide a meaningful
way of overlaying that information (for example, pine isn't available
as a distributable binary, some sources can't be compiled with pgcc,
some architectures may have other requirements).
The simplest way of advertising the contents of the control files would
be to simply extract them and put them in an archive, filed under the
source name. But that doesn't deal with substvars. So we'll need to
think about the way substvars are being used...
In the long run, this looks doable, and worthwhile. However, it's not
going to be trivial. And you have to ask yourself: do we want to stall
supporting source packages until we have a completely evolved system
for source packages?
Or, we can do this in stages:
Version 1: sources can only depend on binary packages.
Version 2: sources can depend on source packages
Version 3: sources can be used to satisfy binary requirements
There might need to be a version 3.1, etc. once we get into the details
of local variations built using source packages. [And version 3 is
only loosely specified at this point -- if we do this right a lot of
-dev packages would go away, and a lot of our discussions about what
architectures to support would focus more on specific bugs than on where
to store the archives.]
One thing to keep in mind: most packages should be unaffected by this
evolution. Genuine bugs [package won't build] need to be addressed,
but we would have a fairly long analysis period before version 3 issues
could be finalized.
While I'm dreaming: It would be nice if we would accept bug reports
about our packages not converting properly to rpm format, but for that to
happen we'd need to have some way of deciding when it's a bug in the rpm
system vs. when it's a bug of ours. [Yeah, I think that for the long term
benefit of the linux community we need to work more closely with Red Hat,
Caldera, SuSE, etc.]
--
Raul
Reply to: