Re: Maintainership, vanishing or absent maintainers (QA)

[Davide G. M. Salvetti]

* WA => Wichert Akkerman

WA> If any random user does this things get messy which is the last
WA> thing that should happen.

I think the right thing would be any random developer who feel
inclined to do a patched deb ASAP, should to it, put it in some
available place on the net, and drop a note both to the maintainer and
the security team, leaving up to those people to decide if and when
that patch should be uploaded as a Debian package.

Cheers,

-- 
Davide G. M. Salvetti -- IW5DZC

Package Dependencies

[Adrian Lopez]

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.

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.

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?

=
= int lrn(int iq) {if(iq>PLANT)return iq;return lrn(iq*2);} =
 lrn([EMAIL PROTECTED]): too deep recursion 
=

solved (was: Re: Package Dependencies

[Marcus Brinkmann]

On Wed, Mar 31, 1999 at 06:36:44PM -0400, Adrian Lopez wrote:
> 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".

Package: equivs
Priority: extra
Section: admin
Installed-Size: 37
Maintainer: Martin Bialasinski <[EMAIL PROTECTED]>
Architecture: all
Version: 1.999.3
Depends: debhelper, dpkg-dev, make, libtricks | fakeroot
Filename: dists/unstable/main/binary-i386/admin/equivs_1.999.3.deb
Size: 9358
MD5sum: 6c887b2c0686115052e9ad5bc55a05b1
Description: Circumventing Debian package dependencies
 This is a dummy package which can be used to create Debian
 packages, which only contain dependency information.
 .
 This way, you can make the Debian package management
 system believe that equivalents to packages on which other
 packages do depend on are actually installed.
 .
 Another possibility is creation of a meta package. When this
 package contains a dependency as "Depends: a, b, c", then
 installing this package will also select packages a, b and c.
 Instead of "Depends", you can also use "Recommends:" or
 "Suggests:" for less demanding dependency.
 .
 Please note that this is a crude hack and if thoughtlessly used
 might possibly do damage to your packaging system. And please
 note as well that using it is not the recommended way of dealing
 with broken dependencies. Better file a bug report instead.


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org   finger brinkmd@ 
Marcus Brinkmann  GNUhttp://www.gnu.org master.debian.org
[EMAIL PROTECTED]for public  PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/   PGP Key ID 36E7CD09

Re: solved (was: Re: Package Dependencies

[Adrian Lopez]

Marcus Brinkmann wrote:
> 
> Package: equivs

Hello... I would have never thought of looking for such a package. It
would really be much better to have a way of doing the same by using
built in features in the package management system's frontend program.
It would be more visible this way, and less of a hack.

=
= int lrn(int iq) {if(iq>PLANT)return iq;return lrn(iq*2);} =
 lrn([EMAIL PROTECTED]): too deep recursion 
=

Re: solved (was: Re: Package Dependencies

[Mitch Blevins]

In foo.debian-policy, Adrian Lopez wrote:
> Marcus Brinkmann wrote:
> > Package: equivs
> 
> Hello... I would have never thought of looking for such a package. It
> would really be much better to have a way of doing the same by using
> built in features in the package management system's frontend program.
> It would be more visible this way, and less of a hack.

This could be harmful.  I assume you are talking about some key-combination
in dselect that when pressed would create an empty package with the
same name and dependency info as the currently selected package.
Adding a local package and tricking the package management system into
believing that it is a normal package *is* a hack, and making it easy
to do from dselect would only legitimize it in the eyes of the userbase,
encourage its use, and make bug-hunting that much harder.

-Mitch