Re: (in lieu of a) Vendor field on .debs (was practical problems with GR)
On Mon, Jun 12, 2000 at 03:13:03PM +0100, Anton Ivanov wrote:
> > On Mon, Jun 12, 2000 at 10:48:33AM +0100, Anton Ivanov wrote:
> You cannot file bugs affecting foreign packages either now (and this is good).
> As the packages you noted are neither in debian nor have been tested for
> compatibility so it is OK.
I agree.
> I am speaking about something else:
>
> What about the logical situation when the vendor offers debs, has a debbugs
> compatible BTS and the package is distributed with debian.
Hmm, there are two possible situations: The vendor honors the Debian BTS
or it he/she/it doesn't. (In the latter case it would be questionable
if such a package should be distributed with Debian, tough.)
> > > I would rather suggest keeping a list of vendors that have complied with the
> > > a few principles on how to maintain the stuff. If it comes from them bug goes
> > > to their BTS cc'ed into Debian BTS.
> > > If it comes from vendors off the list than dpkg should ask a question with
> > > appropriate priority with something like "Dependencies on this package have
> > > not been verified and the package is not being tracked by the Debian BTS".
> > > Some other verbal voodo may follow.
> >
> > Thereby dividing debs into "good" and "bad" or "first-class" and
> > "second-class". That's surely not the way to go.
>
> Sure it is ;-) They are good and bad. first class and second-class. Compliant
> with the package policy and non-compliant. With b0rken dependencies and with
> dependencies that are proper.
But if a vendor is not on that list that doesn't necessarily mean that
his debs are necessarily broken (dependency- and policy-wise). I am
building debs myself (without being a developer) for internal use only.
Nevertheless I take care that they are policy-compliant. I would hate
to see a warning-message whenever I try to install my perfectly ok debs.
Furthermore it may be a problem for vendors to rely on a third party
(ie the Debian maintainers responsible for updating the "good-list")
to create debs that are fine.
Also I personally have a problem to have a general-purpose tool like
dpkg make "ethical" decisions, ie: "Is this package good because the
Debian developers say the vendor makes 'good' packages?"
> Then, why not allow people who wish to deal with non-free software to certify
> that that software works with debian? And make the certification official?
It is a nice idea to allow Debian to certify non-free packages for Debian
compliance if the GR is accepted. I really like this. But I do not think
that dpkg is the right place to distinguish between certified ("good")
and non-certified ("bad") packages. I would rather like to see such
a functionality in package retrieval systems like apt. Another problem is
that it should be configurable on whom to trust on certifications.
Instead of having a list of certified vendors, for example apt's
sources.list could contain a flag for each trusted vendor. Debian
(or another vendor packaging apt) could then provide a sources.list
file, containing many different vendors with 'certified' flags set
at the right positions.
> And keep the bugs tracked properly?
With an appropriate header in packages bugs could get tracked probably
by submitting bug reports to the vendor.
- Sebastian
Reply to: