Re: [PROPOSAL] Origin and Bugs support
On Sun, 26 Nov 2000, Wichert Akkerman wrote:
> Previously Jason Gunthorpe wrote:
> > Yes, because you ingored the discussion on -policy and implemented
> > whatever you wanted and then expected it to just become accepted.
>
> Because in my opinion that discussion didn't produce any good
> alternative.
It did point out a ton of short falls with what you have proposed.
Stopping the dicussion, declaring there to be no alternatives an
implementing your idea is hardly constructive.
> Debian has its own BTS. WTF would you want a Debian package use an
> alternative BTS? It is either a real part of the distribution and should
> be treated as such, or not.
The Origin tag should declare what vendor the package came from - in this
case that is clearly Debian. Setting it to anything else is wrong and
misleading.
I think the rational that test/beta packages be able to not use our the
BTS is quite fair.
> > Having APT maintain the cannonical Origin data as it collects the
> > information from CDs and remote sites is a really good idea which would
> > make this scheme alot more worthwhile. It would break for fewer people
> > than what you are pushing!
>
> So tell me what I'm breaking? I haven't yet heard anything that breaks.
Remeber the last dicussion?
Why do you have a BTS Tag ---> In case there is no origin file
Why do you have an origin file ---> In case the BTS tag is wrong
How do you get an origin file ---> Install the right package
Can't you see that is rediculous!?!
If you don't have an origin file and you need one (because the BTS tag is
wrong) then it breaks
If you have an origin file and it is out of date then it breaks
If you want to override the origin file then you loose
> What are you trying to achieve with not tagging Debian packages? If a
> derived distro wants to get bugreports for a modified package they have
> to change it anyway and don't need to modify /etc/dpkg/origins/debian.
> If they don't then the default setup is just fine.
Same thing I said before -- it makes no sense for a commercial dist user
to ever send bugs to us -- unless they are using our special package
areas (Like the X beta deb, APT beta debs, the wine snapshots etc)
Doubt that? Maybe you should ask them..
I did, guess what they said.. (See Eric's email)
Anyhow - You want alternatives, here we go:
There are two classes of packages:
#1 Debian Shared (between our derived dists)
#2 Vendor Add Ons
Derived dists want all bugs for group 1 to go to them before they go to us
so that they can see if it is an issue they created, an important customer
request, etc. They would probably also would want this so they can say
'Look! Foo 2.4 fixes your bug! You should upgrade!!'
#2 is clearly the main issue, vendors like Helix, Oracle, etc will want to
collect bug reports for their product no matter what it in installed on.
This will become a particulaly strong issue when/if the LSB gets its
packaging act together and we are flooded with non Debian packages.
IMHO due to this any solution must be sellable as part of the LSB
packaging standard.
Since there is a migration problem here as well it makes sense to define
Debian Shared packages as having no origin.
Adding an Origin tag to the other packages is an easy way to tell where
the package came from. As others pointed out using the origin tag to map
to the BTS/Contact/Etc data is a good idea. I would really like to not
limit such a scheme to just BTS but to include a full description of the
vendor including tech support phone numbers, home pages, and the like (APT
GUIs can show this information, as well as the bug/support tools)
Now the hard problem of getting the origin description file. For Debian
Shared type packages this would just be included in some core package of
each derived dist.
For vendor packages I think there are really only two options te deliver
the file:
1) Dynamic Queries by APT/Bug Tools
2) Including them in the package.
I say we should do both in such a way that old data is automatically
discarded (ie version the stuff!) This hurts as few users as possible,
lets us extend the included data dynamically for those lucky enough to
have a net connection, etc. Companies move, phone numbers change, etc so
being able to keep cuurent is important!
For #2 an easy way is to just drop another file in the control tar.gz and
have dpkg update a shared directory on extract, doing the proper newness
test. I am not sure how rpm could do that, buth I think a similar trick
would work for them.
So we would have /var/lib/ISV/ (or something) that contained nice XML
files that are effectively buisness cards for the ISV, APT and dpkg would
co-operate in keeping the files up to date, the files would always exist.
I think this is something the LSB might swallow - we could certainly ask
them!
So there is a reasonable start for an alternative.
Jason
Reply to: