udev rules from package stlink are not being parsed and triggered
Hello, Newbie about udev concepts here. I included stlink package as part of my package list in my system configuration. I can see that there are rules files under /run/current-system/profile/etc/udev/rules.d/ like so: sh> ls -l /run/current-system/profile/etc/udev/rules.d/ total 16 lrwxrwxrwx 1 root root 91 Dec 31 1969 49-stlinkv1.rules -> /gnu/store/zpqb5vydhxkr5ggw767m4hkpi8263yvz-stlink-1.7.0/etc/udev/rules.d/49-stlinkv1.rules lrwxrwxrwx 1 root root 93 Dec 31 1969 49-stlinkv2-1.rules -> /gnu/store/zpqb5vydhxkr5ggw767m4hkpi8263yvz-stlink-1.7.0/etc/udev/rules.d/49-stlinkv2-1.rules lrwxrwxrwx 1 root root 91 Dec 31 1969 49-stlinkv2.rules -> /gnu/store/zpqb5vydhxkr5ggw767m4hkpi8263yvz-stlink-1.7.0/etc/udev/rules.d/49-stlinkv2.rules lrwxrwxrwx 1 root root 91 Dec 31 1969 49-stlinkv3.rules -> /gnu/store/zpqb5vydhxkr5ggw767m4hkpi8263yvz-stlink-1.7.0/etc/udev/rules.d/49-stlinkv3.rules I using the stlink V2 usb device. So when I plug in the stlink v2, udev should create a symlink /dev/stlinkv2_blah But that is not happening. I also did a sh> sudo udevadm test (udevadm info -q path -n /dev/bus/usb/002/006) that shows it is reading only files from eudev pacakge with output lines like Reading rules file: /gnu/store/2l46l7628xyrpwzrymzd3bgrz3n8zf2x-eudev-3.2.11/lib/udev/rules.d/ etc Seeking help Thanks, Milind
Re: duplicate package names in channels
It does help 6/5 ! Thank you for your time and explanation… not to mention the swiftness ! Best regards, Fulbert Le Fri, Sep 30, 2022 at 10:01:39PM +0200, Julien Lepiller a écrit : > Build results are kind of content-addressed, so when two separate packages > yield the same hash, it means they are the same package, and no rebuild is > necessary. > > For the other two questions, it depends from which perspective you're looking > at. From the code point of view, there are no difference between packages > from guix and a channel. When two packages yield a different hash, they are > considered different, so both are built if needed. Also, the code has direct > reference to a given package, you can't reference "whatever provides gcc", > you have to reference a specific gcc package, either from a channel or from > the main guix. > > So from the code point of view, two packages may have the same name and even > version, and this is never ambiguous. Because packages are stored as Guile > variables and when you specify a variable name it can only reference one > value. > > From the user point of view, esp. the CLI, you seem to have noticed that guix > will chose the highest version number when you ask for a package without an > explicit version number. This does not change whether packages come from a > channel or from guix. > > When two packages have the same name and version, guix will arbitrarily (but > reproducibly :p) chose one or the other. > > HTH! > > Le 30 septembre 2022 21:48:31 GMT+02:00, Fulbert a écrit > : > >Hello ! > > > >I'm not sure if guix supports similar package names [and version number] > >provided in more than one “active” channels (declared in the list of > >'~/.config/guix/channels.scm, including %default-channels)… > >a) if 2 packages share their name, version and package definition, > >yielding the exact same result, thus sharing the same hash and > >/gnu/store/ storage-space (one “recognizing” the other hash, avoiding > >redondant build or conflict ?) ; > >b) if 2 packages share their name but not the version, thus yielding > >distinct hashes, could guix automatically choose the highest available > >version, similar to what guix does when it provides multiple versions of > >the same name package in the main 'guix channel ? ; > >c) if 2 packages share their name and version but do not yield the same > >result/hash (… that's the only case where I'm abble to see a conflict). > > > >As far as i understand, (c) would be problematic, thus (a) would require > >a pre-build of both and conflict management, which is unlikely(?) and > >consequently, (b) would require a user to remove manually a package in > >the additionnal channel before it leads to (a). > > > >So, my guess work gives NO, NO and NO, but I would be gratefull if > >someone could confirm, eventually with a pointer to the manual or other > >doc. (I am unable to check that for myself in the sources with any > >degree of comprehension, let alone certainty ^^) > > > >Thanks for guix and best regards, > >Fulbert > >
Re: duplicate package names in channels
Build results are kind of content-addressed, so when two separate packages yield the same hash, it means they are the same package, and no rebuild is necessary. For the other two questions, it depends from which perspective you're looking at. From the code point of view, there are no difference between packages from guix and a channel. When two packages yield a different hash, they are considered different, so both are built if needed. Also, the code has direct reference to a given package, you can't reference "whatever provides gcc", you have to reference a specific gcc package, either from a channel or from the main guix. So from the code point of view, two packages may have the same name and even version, and this is never ambiguous. Because packages are stored as Guile variables and when you specify a variable name it can only reference one value. From the user point of view, esp. the CLI, you seem to have noticed that guix will chose the highest version number when you ask for a package without an explicit version number. This does not change whether packages come from a channel or from guix. When two packages have the same name and version, guix will arbitrarily (but reproducibly :p) chose one or the other. HTH! Le 30 septembre 2022 21:48:31 GMT+02:00, Fulbert a écrit : >Hello ! > >I'm not sure if guix supports similar package names [and version number] >provided in more than one “active” channels (declared in the list of >'~/.config/guix/channels.scm, including %default-channels)… >a) if 2 packages share their name, version and package definition, >yielding the exact same result, thus sharing the same hash and >/gnu/store/ storage-space (one “recognizing” the other hash, avoiding >redondant build or conflict ?) ; >b) if 2 packages share their name but not the version, thus yielding >distinct hashes, could guix automatically choose the highest available >version, similar to what guix does when it provides multiple versions of >the same name package in the main 'guix channel ? ; >c) if 2 packages share their name and version but do not yield the same >result/hash (… that's the only case where I'm abble to see a conflict). > >As far as i understand, (c) would be problematic, thus (a) would require >a pre-build of both and conflict management, which is unlikely(?) and >consequently, (b) would require a user to remove manually a package in >the additionnal channel before it leads to (a). > >So, my guess work gives NO, NO and NO, but I would be gratefull if >someone could confirm, eventually with a pointer to the manual or other >doc. (I am unable to check that for myself in the sources with any >degree of comprehension, let alone certainty ^^) > >Thanks for guix and best regards, >Fulbert >
duplicate package names in channels
Hello ! I'm not sure if guix supports similar package names [and version number] provided in more than one “active” channels (declared in the list of '~/.config/guix/channels.scm, including %default-channels)… a) if 2 packages share their name, version and package definition, yielding the exact same result, thus sharing the same hash and /gnu/store/ storage-space (one “recognizing” the other hash, avoiding redondant build or conflict ?) ; b) if 2 packages share their name but not the version, thus yielding distinct hashes, could guix automatically choose the highest available version, similar to what guix does when it provides multiple versions of the same name package in the main 'guix channel ? ; c) if 2 packages share their name and version but do not yield the same result/hash (… that's the only case where I'm abble to see a conflict). As far as i understand, (c) would be problematic, thus (a) would require a pre-build of both and conflict management, which is unlikely(?) and consequently, (b) would require a user to remove manually a package in the additionnal channel before it leads to (a). So, my guess work gives NO, NO and NO, but I would be gratefull if someone could confirm, eventually with a pointer to the manual or other doc. (I am unable to check that for myself in the sources with any degree of comprehension, let alone certainty ^^) Thanks for guix and best regards, Fulbert
