On Sun, 7 Jun 2009 21:21:36 +0200 Raphael Hertzog <hert...@debian.org> wrote:
> On Sun, 07 Jun 2009, Neil Williams wrote: > > The behaviour with DEB_VENDOR should match the behaviour with --vendor > > and there should be some way of handling vendor names that include > > spaces without needing to use quote marks when using the environment > > variables or --vendor options. > > Those options expect a vendor name and not a > filename. There's no documentation, so how am I to know what those options expect? The vendor name is neither accepted, nor desirable because it is too long. The full vendor name is actually likely to be: Emdebian Crush 2.0 (based on Debian 6.0 "Squeeze") Do you really want me to have to create a dpkg conffile with all that detail encoded within? Further to that, machine:variant customisation support within Emdebian Crush allows for multiple variations and sub-vendor configurations that all need the dpkg-vendor interface. emdebian-crush-balloon3-gpe emdebian-crush-balloon3-maemo emdebian-crush-nslu2 emdebian-crush-ldap etc. Each implementation has mutually incompatible package dependencies and functionality changes. (The removal of all ldap support being one of the most common changes from regular Debian, along with the absence of both perl and python.) The vendor names should be human readable and I see no reason why dpkg-vendor has to have a match between the descriptive name and the filename - nor is such a stipulation documented anywhere. > You misused the interface by passing "emdebian-crush" instead of > the vendor name. I cannot pass the vendor name - it has a space. There should be no requirement to create a conffile with a space in the filename merely to satisfy (a bug in) the Dpkg API. $ dpkg-vendor --vendor "emdebian grip" --query bugs dpkg-vendor: error: vendor emdebian grip doesn't exist in /etc/dpkg/origins/ Besides, I cannot "misuse" an interface that has not documented the proper use case. > > It is inconsistent that the command line option works one way and the > > environment variable works another way. It would be better to look only > > for the matching filename and then use the value for the field from > > that file. > > It's inconsistent, yes, but it's working correctly when you follow the rules. No, it does not work and there are no rules documented anywhere, you've already mentioned that. > I can make it reject emdebian-crush if you want but my opinion is that > being tolerant in what I accept is the right behaviour for me. It should not need to check the filename against the vendor name - the two can be entirely separate. Irrespective of the space, the fact remains that the two interfaces give different results. > > If the supplied argument matches the filename, why bother > > cross-checking that with the Vendor: field inside the file? I would > > have thought that the field can be the longer, descriptive title and > > the filename can be a shortened version. > > It's not done on purpose, it's just an implementation detail and a > consequence of the current Dpkg::Vendor API. i.e. a bug. > > Currently, if the file specified originally has the Vendor changed from > > the correct title "Emdebian Crush" to the corrupted form > > "Emdebian-Crush", then dpkg-vendor works in the same way with both > > forms. This change should not be necessary. > > Create the file "/etc/dpkg/origins/Emdebian Crush" and use "Emdebian > Crush" as vendor name everywhere (DEB_VENDOR, --vendor) and it will work > too. A conffile with a space in the filename is just plain ugly. Capitalising it even worse. I see no valid reason for stipulating that the filename must be strictly derivable from the Vendor name, it merely has to be unique in the /etc/dpkg/origins/ directory. > > What is the reason for the duplicate check? > > Implementation detail... in one case, get_current_vendor() is used (and > returns the name inside the file instead of returning the original name) > and in one case the vendor name is taken directly from the command line. Then it is a bug - two different mechanisms for the same interface giving disparate results. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
