[gentoo-dev] Last rites: media-sound/lastfmplayer
# Michael Palimamka (11 Feb 2018 # Fails to build (bug #538400). Requires dead Qt 4 (bug #637014). # Dead upstream. Masked for removal in 30 days. media-sound/lastfmplayer
Re: [gentoo-dev] Re: newsitem: baselayout 2.5 changes
On Sat, Feb 10, 2018 at 12:15:43PM -0600, William Hubbs wrote: > On Sat, Feb 10, 2018 at 03:34:51PM +, Duncan wrote: > > William Hubbs posted on Thu, 08 Feb 2018 13:52:56 -0600 as excerpted: > > *snip* > > > > The second change is that baselayout is taking ownership of most of the > > > directories it creates. This includes all directories in / and /usr > > > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB, > > > baselayout will take ownership of /lib* and /usr/lib* as well. > > > > What's the effect if the "directory" is a symlink to elsewhere? > > When we try to replace the symlink with a directory, the emerge will > fail. It looks like this isn't quite correct, portage doesn't fail to emerge the package, but it doesn't replace the symlink with the directory either. You may be ok, but you'll have to test. This is all very custom (Gentoo makes these things as directories when the stages are built, so it won't be an issue for a default installation). > > Here, the following system "directories" are actually symlinks: > > > > # makes installing grub to multiple devices much easier > > /boot -> /bt > > > > # "reverse" usrmerge > > /usr -> . > > > > # would be /usr/games, but with reverse usrmerge... > > /game -> . > > > > # shorter path > > /home -> h > > > > # lib(64) merge (including /usr/lib(64) > > /lib -> lib64 > > When we get rid of symlink_lib, we will expect both of these (/lib and > /lib64) to be directories. Mgorny can explain more about this, but > linking lib to lib64 is basically a hack. > > > > > > # would be /usr/local, /l is so much shorter > > /local -> l > > > > # (s)bin merge (including /usr/(s)bin) > > /sbin -> bin > > This will be taken care of in the usr merge support. > > > > > # shouldn't appear on a desktop/workstation system, but bugs... > > /srv -> tmp > > Keep in mind that /tmp is wiped during a reboot, so /srv should be > separate from /tmp. > > > > > # shorter log path (/lg as /l already taken by local) > > /var/log -> /lg > > > > > Third is the beginning of support for the /usr merge through the > > > addition of the usrmerge use flag. > > > DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN > > > HELP WITH TESTING. > > > > What about "reverse" usrmerge as above? Flag on or not? Maybe I just > > turn it on (obviously after updating my backups) to help test? > > The "reverse" usr merge as you call it is a highly custom configuration; > I do not see us building it into baselayout. However, like I said above, > the baselayout changes will not stop you from configuring this using a > combination of /etc/portage/package.env and /etc/portage/env/baselayout. > > William > signature.asc Description: Digital signature
Re: [gentoo-dev] Re: newsitem: baselayout 2.5 changes
On Sat, Feb 10, 2018 at 03:34:51PM +, Duncan wrote: > William Hubbs posted on Thu, 08 Feb 2018 13:52:56 -0600 as excerpted: *snip* > > The second change is that baselayout is taking ownership of most of the > > directories it creates. This includes all directories in / and /usr > > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB, > > baselayout will take ownership of /lib* and /usr/lib* as well. > > What's the effect if the "directory" is a symlink to elsewhere? When we try to replace the symlink with a directory, the emerge will fail. You will want to take a look at using /etc/portage/package.env and /etc/portage/env/baselayout to set INSTALL_MASK to not install things that collide if you want to keep this setup. https://wiki.gentoo.org/wiki//etc/portage/package.env > Here, the following system "directories" are actually symlinks: > > # makes installing grub to multiple devices much easier > /boot -> /bt > > # "reverse" usrmerge > /usr -> . > > # would be /usr/games, but with reverse usrmerge... > /game -> . > > # shorter path > /home -> h > > # lib(64) merge (including /usr/lib(64) > /lib -> lib64 When we get rid of symlink_lib, we will expect both of these (/lib and /lib64) to be directories. Mgorny can explain more about this, but linking lib to lib64 is basically a hack. > > # would be /usr/local, /l is so much shorter > /local -> l > > # (s)bin merge (including /usr/(s)bin) > /sbin -> bin This will be taken care of in the usr merge support. > > # shouldn't appear on a desktop/workstation system, but bugs... > /srv -> tmp Keep in mind that /tmp is wiped during a reboot, so /srv should be separate from /tmp. > > # shorter log path (/lg as /l already taken by local) > /var/log -> /lg > > > Third is the beginning of support for the /usr merge through the > > addition of the usrmerge use flag. > > DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN > > HELP WITH TESTING. > > What about "reverse" usrmerge as above? Flag on or not? Maybe I just > turn it on (obviously after updating my backups) to help test? The "reverse" usr merge as you call it is a highly custom configuration; I do not see us building it into baselayout. However, like I said above, the baselayout changes will not stop you from configuring this using a combination of /etc/portage/package.env and /etc/portage/env/baselayout. William signature.asc Description: Digital signature
Re: [gentoo-dev] SAT-based dependency solver: request for test cases
On 10/02/2018 09:20, Michał Górny wrote: > To be honest, I don't think this is the right approach to the problem. Feel free to suggest a better one. > Truth is, dependencies in Gentoo are seriously broken, and most of > the developers aren't even aware of that because of layers upon layers > of hacks in Portage that make emerge somewhat go on. Indeed, I may not be aware of many such problems. Is there a place where the known ones can be documented? Paweł signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: newsitem: baselayout 2.5 changes
William Hubbs posted on Thu, 08 Feb 2018 13:52:56 -0600 as excerpted: > here is a proposed newsitem for baselayout 2.5. > There are three significant changes in baselayout-2.5. > > The first change is that ROOTPATH is no longer set. This means all of > the *sbin directories will be added to the default path for all users > instead of just the root user. Makes sense and is important for users to know. > I know of no packages outside of > baselayout that used the ROOTPATH variable; however, if packages do use > it, they will need to be adjusted to use PATH instead. Omit that as dev, not user, focused? > The second change is that baselayout is taking ownership of most of the > directories it creates. This includes all directories in / and /usr > excluding /lib* and /usr/lib*. Once we drop support for SYMLINK_LIB, > baselayout will take ownership of /lib* and /usr/lib* as well. What's the effect if the "directory" is a symlink to elsewhere? Here, the following system "directories" are actually symlinks: # makes installing grub to multiple devices much easier /boot -> /bt # "reverse" usrmerge /usr -> . # would be /usr/games, but with reverse usrmerge... /game -> . # shorter path /home -> h # lib(64) merge (including /usr/lib(64) /lib -> lib64 # would be /usr/local, /l is so much shorter /local -> l # (s)bin merge (including /usr/(s)bin) /sbin -> bin # shouldn't appear on a desktop/workstation system, but bugs... /srv -> tmp # shorter log path (/lg as /l already taken by local) /var/log -> /lg > Third is the beginning of support for the /usr merge through the > addition of the usrmerge use flag. > DO NOT, DO NOT TURN THIS ON UNLESS YOU KNOW WHAT YOU ARE DOING AND CAN > HELP WITH TESTING. What about "reverse" usrmerge as above? Flag on or not? Maybe I just turn it on (obviously after updating my backups) to help test? -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
W dniu sob, 10.02.2018 o godzinie 10∶49 +, użytkownik Mike Auty napisał: > On 08/02/18 20:55, Mike Gilbert wrote: > > However, there are plenty of examples of commands that normal users > > may run from sbin. > > Hiya, > > I'm not really for or against the idea, but whenever the justification > for something is "there are plenty of examples" it's really helpful to > have a number of them listed so that people can see what actual benefit > is being provided by the change. Could you name a few of the most > common/important examples so that it's part of the discussion please? > blkid btrfs iwconfig swapon I think historically also 'ifconfig' and 'ping' were in sbin. Sure, those commands are often used by root. But I don't need elevated privileges to want to know my free space or IP address. -- Best regards, Michał Górny
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On 08/02/18 20:55, Mike Gilbert wrote: > However, there are plenty of examples of commands that normal users > may run from sbin. Hiya, I'm not really for or against the idea, but whenever the justification for something is "there are plenty of examples" it's really helpful to have a number of them listed so that people can see what actual benefit is being provided by the change. Could you name a few of the most common/important examples so that it's part of the discussion please? Mike 5:) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] SAT-based dependency solver: request for test cases
W dniu sob, 10.02.2018 o godzinie 11∶20 +0100, użytkownik Ulrich Mueller napisał: > > > > > > On Sat, 10 Feb 2018, Michał Górny wrote: > > Example: many packages have impossible circular dependencies. > > However, Portage conditionally pretends they don't exist, preferring > > some random install-time breakage over fixing the packages in > > question. > > Isn't that what the PMS allows, though? RDEPEND must be fulfilled, > "unless the particular dependency results in a circular dependency, > in which case it may be installed later". > Yes, and I regret ever adjusting this to match the horribly misjudged Portage behavior. -- Best regards, Michał Górny
Re: [gentoo-dev] SAT-based dependency solver: request for test cases
> On Sat, 10 Feb 2018, Michał Górny wrote: > Example: many packages have impossible circular dependencies. > However, Portage conditionally pretends they don't exist, preferring > some random install-time breakage over fixing the packages in > question. Isn't that what the PMS allows, though? RDEPEND must be fulfilled, "unless the particular dependency results in a circular dependency, in which case it may be installed later". Ulrich pgpXtmrhff4GE.pgp Description: PGP signature
Re: [gentoo-dev] SAT-based dependency solver: request for test cases
W dniu wto, 06.02.2018 o godzinie 11∶52 +0100, użytkownik Michael Lienhardt napisał: > Dear all, > > With the help of some friends and colleagues, I am working on an SAT-based > dependency solver for portage. > We need your help to test it and possibly improve in the long run the already > great portage toolset. > > To help, you can send us the tar generated by this bash script: > https://raw.githubusercontent.com/HyVar/gentoo_to_mspl/master/benchmarks/get_installation.sh > This bash script extracts your world file, the USE flags and keywords > configuration of your system and the list of installed packages you have (it > should not take more than few seconds). > With this, we will see if our solver is able to recreate your system and how > much time it takes. > To be honest, I don't think this is the right approach to the problem. Truth is, dependencies in Gentoo are seriously broken, and most of the developers aren't even aware of that because of layers upon layers of hacks in Portage that make emerge somewhat go on. If you are really able to build something on top of the input you receive, it's probably going to be even worse than what's already in Portage. Example: many packages have impossible circular dependencies. However, Portage conditionally pretends they don't exist, preferring some random install-time breakage over fixing the packages in question. -- Best regards, Michał Górny
