[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hplip package (work in progress)

From: Danny Milosavljevic
Subject: Re: hplip package (work in progress)
Date: Sun, 20 Mar 2016 01:19:04 +0100


On Wed, 16 Mar 2016 09:45:12 +0100
Andy Wingo <address@hidden> wrote:

> > Generally, yes.  If it later needs to be merged into a common /etc/cups  
>                 ^, put it in the hplip store directory
> > directory for some reason, then cups-service needs to create a union
> > directory based on the etc/cups directories in a set of packages.  See  
> > polkit-service for an example.

It's trying to update mime.types of cups in order to add pstotiff 
(pstotiff.convs and pstotiff.types) to it.

hplip's "configure" checks whether there is /usr/share/cups/mime/mime.types . 
If there is, it prefers that.
Otherwise, it tries to use /etc/cups .

It can be overridden by configure-flag --with-mimedir=... or disabled by 

However, I think in this case we have to merge the current system's mime.types 

Checking for mime-types in guix, I found
- ruby mime types
- perl mime types
- cups mime types
- haskell mime types

I guess in this case we should use cups mime types.

cups.scm fiddles around with cups mime types for some tests and also for 
installation ('install-cups-filters-symlinks).

$out/share/cups/mime/cupsfilters.types and 
$out/share/cups/mime/cupsfilters.convs and $out/share/cups/drv/cupsfilters.drv 
and $out/share/ppd .

I think all of these need to do some merging. Cups already does symlink the 
mime config files from package "cups-filters" into its output dir - but it does 
not merge.

I also checked polkit-service and it seems to use something called "service 
extensions" in order to concatenate all the different actions.

It seems to use polkit-configuration-actions (which is always empty? - how does 
this get set?)

I'd like to ask for help on this, I have no idea how this part works in Guix.

Then, after all this, hplip has hardcoded inside :

# hpmud.rules
rulesdir = /etc/udev/rules.d
dist_rules_DATA = data/rules/56-hpmud_sysfs.rules
dist_rules_DATA = data/rules/56-hpmud.rules

halpredir = /usr/share/hal/fdi/preprobe/10osvendor
dist_halpre_DATA = data/rules/20-hplip-devices.fdi

# hplip.conf
hplip_confdir = /etc/hp
hplip_conf_DATA = hplip.conf

# hplip.state
hplip_statedir = /var/lib/hp
dist_hplip_state_DATA =

Should we substitute those? (I'm already autogen'ing, so it doesn't matter to 
substitute some more things)

What about /etc/hp/hplip.conf ? Should it be autogenerated (or should we let 
hp-setup write it?) and we just put the distfile into the store as an example? 

I don't think we use hal, so I'll just let it install a useless file, if it 
absolutely has to. Lirc seems to do the same.

It seems the udev files are already being merged by services/base , right?

I tried to find the generated udev.conf files, and there is for example (I 

50-udev-default.rules:KERNEL=="fuse", MODE="0666", OPTIONS+="static_node=fuse"
99-fuse.rules:KERNEL=="fuse", MODE="0666"

I think that's why fuse autoloading doesn't work anymore.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]