Quoting Brederlow <[EMAIL PROTECTED]>:
> Adrian Lopez <[EMAIL PROTECTED]> writes:
>
> > The purpose of this message is to inspire discussion with respect to
> > Debian's package dependency issues. I apologise if this is not the
> > proper venue for this, but I felt that the dpkg and deity development
> > lists would be even less appropriate. I also apologise if this has been
> > discussed before. I'm not extremely familiar with Debian's lists.
> >
> > Often I like building my own packages from tar.gz sources, both for
> > regular programs and for development libraries. I also like using
> > dselect for managing those packages which I don't compile myself. This
> > way of doing things is sometimes difficult because of certain package
> > dependencies, both hard and suggested. This is a problem, as I don't
> > like having to manually override package installation every time I
> > install something new. I really don't want to cease using dselect, but
> > it can be trouble sometimes.
>
> Why use just tar.gz files? Use the .dsc files (if you don`t already
> do) and use "debuild" (or build on slink). I think thats in
> "devscripts". "debuild" will build you a .deb package from the debian
> source and (unless disabled by options) also make a diff to the
> original source and sign the packages.
>
> After debuild has run, you can just install the packages via dpkg or
> copy them to some common place and have apt or dselect get them from
> there. That way your dependencies will be set correctly.
I don't think that resolves the problem of a non-debianized tar.gz.
I suggest you to take a look at equivs, who create a 'non-official but
look a like' debian package. It's merily a dummy debian tree which can
get the installed files you want and make a deb files with it.
You can also do it directly with dpkg --build. You should have a
directory with a structure like this one:
-<package-name>-<version>-<debian-version>
+-DEBIAN+-control
+-{post|pre}{inst|rm}
+-<installed files tree with complete path>
I do it a lot of time before becoming a Maintainer myself. Now, I package
it as a debian source package directly.
>
> > I would like to freely customise my system without causing package
> > dependency problems. The best solution I can think of is to be able to
> > "dummy install" any package that is not considered to be "critical". I
> > could dummy install certain libraries, for instance, providing instead
> > my own versions of these libraries. It's about making customization
> > easier.
>
> Thats exactly the wrong way. You should supply correct informations to
> dpkg. What if the new gif lib is incompatible to the one you dummy
> installed last month. Maybe because of the old dummy lib, the new gimp
> wont install, but the old will remain, which doesn`t work with your
> selfmade lib.
Yes that's right, be carefully to give all the Conflicts: and Provides:
fields. Take also note that, currently, dpkg doesn't support versionned
Provides, e.g: Even if dummy-libc_2.1 provides libc, it will only resolve
dependencies on the package name, not the version. The current Policy
ask for such a features but, as it was already said, dpkg need a good
rewrite for such a thing. However, apt is ready for it :)
>
> But even so "dummy install" is a good thing, just for different
> reasons.
>
> > Doing a dummy install should be a trivial matter. It might be as simple
> > as doing a regular install, selecting the package for dummy install with
> > a special key combination (similar to + - _ = : options). All this would
> > do is to satisfy other packages' dependencies requiring the presence of
> > the package being installed; nothing is really installed.
> >
> > I feel this would be a great asset to users who like to compile their
> > own packages from sources other than Debian's, while also preserving
> > some of the benefits inherent in Debian's package system.
> >
> > What do you people think?
>
> That that will be obsolete with some suggestions made on
> debian-admintool, especially (just someone implementing those quickly
> is missing):
>
> - all configuration options must have a working default
> - package might not ask for user interactions, except via ONE
> interface (which will allways take the default [or the database
> entry] as answere, when the "dummy" or "don`t configure" option is
> active).
>
> The above have been suggested in various forms and together with many
> other things, but basically that fits most suggestions.
>
> May the Source be with you.
> Goswin
>
>
------------------------------------------------------------------------
Fabien Ninoles Chevalier servant de la Dame Catherine des Rosiers
aka Corbeau aka le Veneur Debian GNU/Linux maintainer
E-mail: [EMAIL PROTECTED]
WebPage: http://www.tzone.org/~fabien
RSA PGP KEY [E3723845]: 1C C1 4F A6 EE E5 4D 99 4F 80 2D 2D 1F 85 C1 70
------------------------------------------------------------------------
