Re: debmake & dpkg
On Wed, 22 Jan 1997, Ian Jackson wrote:
> I have strong reservations about most of Christoph Lameter's
> proposals:
>
> > - automatically locate packages when just a packagename is given
> > (invoke ftp or whatever means configured to get the package)
> >
> > - automatically install packages depended on by a package
>
> I think that this is the job of dselect. dselect should have a
> `noninteractive' mode where you say:
> dselect --install spong
> and it finds spong and things it depends on and installs them.
In either scenario, how will virtual package dependencies
automatically resolve themselves? There could be any number of
real packages that satisfy a virtual package dependency. I think
that this would need to be very well thought out as it could be
the source of much pain for the end user.
>
> > - some system wide configuration file for how to handle docs /manpages
[snip]
>
> I think that this is best done with pattern-pased file exclusion. I
> don't think that conditional compression is necessary.
This is a good idea and I'll vote for any reasonable
implementation. :-)
>
> > - Checksums stored in the .deb package and a function to verify the
> > integrity of installed files.
>
> My views on per-file checksums are well-known.
Please point me to them as I am unfamiliar (sorry, I'm relatively
new).
>
> > - Get rid of all the single files in /var/lib/dpkg/info and use
> > a database instead to provide faster operation (RPM is much faster
> > than dpkg!). Set up a library interface to access the datastructures
> > which would be a superset of the rpm library so that rpm tools could
> > use the dpkg library (We are hijacking their tools with this move!)
> > rpm could run with the dpkg library and install rpm packages without
> > conversion ....
>
> This is a very bad idea. dpkg's databases are carefully designed to
> avoid bad lossage in case of disk overflow, bad sectors, &c, and to be
> manually fixable when required. Typical database solutions do not
> have these important properties.
What is in place to deal with such incidents of potential data
loss? These look like ordinary ascii files to me. In any case,
these files are not my primary area of concern. The metainfo
stored in /var/lib/dpkg/{available,status} and the Packages files
is very cumbersome to parse in its current format. This should
be restrucured. It could remain an ascii file and still be
restructured. Either that or I'll have to get better at parsing
this stuff ;-)
Richard G. Roberto
richr@bear.com
011-81-3-3437-7967 - Tokyo, Japan
--
*******************************************************************************
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
*******************************************************************************
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: