[Printing-architecture] RE: [Printing-summit] RE: where is th e
info on driver directories
Olaf Meeuwissen
olaf.meeuwissen at avasys.jp
Mon Nov 12 16:11:10 PST 2007
I've got only very little time ...
"Petrie, Glen" <glen.petrie at eitc.epson.com> writes:
> < ... snip ... >
>
>> Eh, why not just add an option to /usr/bin/pdpca to list what is
>> there. For your example:
>>
>> pdpca --dev guten --list
>>
>> You could even have options to get a list of valid arguments for the
>> --dev option. Why make the user navigate the file system if a tool
>> can do it for them?
>
> [gwp] ok, there is a single 'controlling' pdpca application which can invoke
> a developer specific version of a pdpca and the 'controlling' pdpca is
> location in 'foo' with a actual path added to the system $PATH variable.
The "controlling" pdpca lives in /usr/bin/pdpca (on FHS/LSB compliant
systems). Systems that do not even have /usr/bin in their default
PATH are perverse.
> Then the 'controlling' pdpca would have options as
>
> pdpca --list : list the possible developers
> pdpca --devel foo --list : list the options for the developers
>
> to actually execute, use
>
> pdpca [-t,-h,-i,-s] --devel foo [option]
>
> this would now locate and execute the requested/actual pdpca
>
> Now the user/HD does not need to know where the actual pdpca app's are but
> the 'controlling' pdpca will. But again, as you suggest, the system $PATH
> variable is updated to include the developer path to their pdpca.
That's not what I suggested and would unnecessarily pollute the user's
environment. The LSB DDK can take care of symlinking the "actual"
pdpca apps to /usr/bin/, which is in the user's PATH.
> I can [not]
> remember if you suggested using a new system $PDPCA variable which would
> have the path for the actual pdpca software or just use the system $PATH
> variable (which is getting pretty long considering printing is not the only
> thing needing path info).
I did not suggest using a PDPCA environment variable.
> The alternative to using system variables for each developer is to use the
> directory structure I have been proposing along with the 'controlling' pdpca
> (the 'controlling' pdpca does a $PATH entry).
As Till also mentioned, we already have an agreed upon directory
structure. Those "actual" pdpca apps should live in
/opt/<supplier>/bin and can follow the naming convention you
suggested.
> This way printing things are
> collected under one directory and there may not be a need for linking
> (things are in known locations which I see a good approach for the goal of
> making printing easier on Linux including all aspects for retrieving
> capabilities, drivers, etc).
As a matter of fact, I'm also not much in favour of symlinking all
those "actual" pdpca apps below /usr/bin. The "controlling" pdpca can
quite easily search for "actual" pdpca apps in all /opt/<supplier>/bin
directories and build lists dynamically. Even with say a hundred
suppliers with a hunderd test apps each, that would not be a big
overhead. The "controlling" pdpca does not have to be a speed daemon
when it comes to finding the right info/app.
Besides, it could create a cache if speed becomes an issue.
> < ... snip ... >
>
>> FWIW, manufacturer, developer and supplier are three different hats.
>> It just so happens that there's usually only one or two heads wearing
>> them.
>
> [gwp] Actually I would like to see use establish the definition for the
> three entities in context of printing drivers and printers. To get the
> discussion rolling I suggest the following as starting points.
>
> Manufacturer:
> -- The Company, Project, Entity or Person who Company's, Project's, Entity's
> or Person's name is affixed to a hardware unit.
Must be my English, but this doesn't quite parse for me. If you mean:
The Company, Project, Entity or Person whose name is affixed to a
hardware unit.
then that's something I can agree with.
> ----- This means that an OEM company is not the "Manufacturer". Although an
> OEM company produced the actual hardware; the OEM company name is not
> affixed to the product.
>
>
> Developer:
> -- The Company, Project, Entity or Person who Company's, Project's, Entity's
> or Person's name is affixed to a software application.
Same parse error here.
> ----- This means that an OEM software company is not the "Developer".
> Although the OEM company produced the actual software; the OEM company name
> is not affixed to the product.
>
>
> Supplier:
> -- The Company, Project, Entity or Person who distributes the hardware or
> software but may or may not be the Company, Project, Entity or Person who
> Company's, Project's, Entity's or Person's name that is affixed to the
> hardware or software.
And again.
Actually, I think it's enough for a supplier to distribute the
software and have their name affixed to it. I don't see the point of
the hardware distribution part.
> ----- RedHat can be a supplier of Epson Printer Drivers but they are the
> Developer or the Manufacturer. However, when someone refers to "the Epson's
> Printer Driver" which may be produced by an OEM or subcontractor for Epson
> but Epson affixes their name to the driver; then, Epson is still the
> Manufacturer and Developer along with be the possible Supplier.
>
> So for the pdpca application it is not Supplier, but the Developer that is
> being specified.
>
> If the actually printer is being specified, then it we would refer to the
> Manufacturer.
>
> Glen
Hope this helps,
--
Olaf Meeuwissen FLOSS Engineer -- EPSON AVASYS Corporation
FSF Associate Member #1962 sign up at http://member.fsf.org/
GnuPG key: 6BE37D90/AB6B 0D1F 99E7 1BF5 EB97 976A 16C7 F27D 6BE3 7D90
Penguin's lib! -- I hack, therefore I am -- LPIC-2
More information about the Printing-architecture
mailing list