On Sun, 07 Jun 2009, Neil Williams wrote:
> > Those options expect a vendor name and not a
> > filename.
>
> There's no documentation, so how am I to know what those options expect?
--vendor vendor
Assumes the current vendor is vendor instead of discovering it with
the DEB_VENDOR environment variable or /etc/dpkg/origins/default.
What do you think it can be if not the name of the vendor ? It also matches the
field name which is called "Vendor".
>
> 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 can put a longer vendor name in another field if you care.
> I cannot pass the vendor name - it has a space.
Stop being stupid. You can, you might not like it but you can.
> There should be no requirement to create a conffile with a space in the
> filename merely to satisfy (a bug in) the Dpkg API.
I can certainly try to replace spaces by "-" and look up the corresponding
files as well.
Is that what you want ?
There aren't hundreds of solutions, either the name can be used
to find out the corresponding file or I have to scan all the files
and look up if one of them has a corresponding vendor name.
Currently the first solution is implemented and it can be extended
with the space/dash replacement feature, or we can switch to the
other solution.
> Besides, I cannot "misuse" an interface that has not documented the
> proper use case.
The format of /etc/dpkg/origins/* is not documented but dpkg-vendor is
documented. Don't attribute me words I did not say.
> > 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.
Only if I we implement the second way to identify the vendor file for a given
vendor name.
Is that what you want ?
Note you can't have both.
> > > "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.
"/etc/dpkg/origins/emdebian crush" would work as well. I can add logic to
handle "-" instead of "spaces" but you can't make up you mind between several
ways to handle the problem of identifying a vendor file with a vendor name.
> 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.
I see a reason, it's slightly less expensive to parse one file instead of
parsing all until we have found one that matches. In practice, the number of
files will always be a handful and it doesn't matter much.
But it seemed the right approach when I implemented it. I'm open to
improvements but you don't help me in deciding how to improve the situation
by going in all directions.
(That's what I hate when discussing bugreports with you, we lose time on details
because you care too much about some cosmetic details and you can't see the
real problematic behind your request.)
Cheers,
--
Raphaël Hertzog
Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
