[gentoo-user] udev-181 saga continues with udisks (~amd64)

[gentoo-user] udev-181 saga continues with udisks (~amd64)

[Allan Gottlieb]

I have been masking udev-181 so that I can continue to keep my current
system with / and /usr separate partitions.

This has required masking pciutils and usbutils as well.
/etc/portage/package.mask/udev-181 contains
  >=sys-fs/udev-181
  >=sys-apps/pciutils-3.1.9-r2
  >=sys-apps/usbutils-005-r1

Now udisks-1.99.0-r1 wants to pull in a new package udev-init-scripts.
I currently have udisks-1.98.0 which is fine.

I added
  >=sys-fs/udisks-1.99.0
to package.mask/udev-181 and  emerge --pretend --update world reports no
conflicts.

I was about to proceed when I looked at eix udisks and noticed that
1. "my" udisk -1.98.0 is no longer there
2. The 1-99.0-r1 is now in slot 2 and new 1.0.4-r[23] are in slot 0.
   I looked at -r3 and it wants >=udev-171-r5.  Since I have -r6 my sys.
   should meet the requirement.

So I wonder if my mask >=sys-fs/udisks-1.99.0 is a bad idea and I should
instead be forcing/encouraging udisks-1.0.4-r3 (and, if so, how?).

thanks,
allan

Re: [gentoo-user] udev-181 saga continues with udisks (~amd64)

[Canek Peláez Valdés]

On Sun, Aug 12, 2012 at 12:47 PM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
> I have been masking udev-181 so that I can continue to keep my current
> system with / and /usr separate partitions.
>
> This has required masking pciutils and usbutils as well.
> /etc/portage/package.mask/udev-181 contains
>   >=sys-fs/udev-181
>   >=sys-apps/pciutils-3.1.9-r2
>   >=sys-apps/usbutils-005-r1
>
> Now udisks-1.99.0-r1 wants to pull in a new package udev-init-scripts.
> I currently have udisks-1.98.0 which is fine.
>
> I added
>   >=sys-fs/udisks-1.99.0
> to package.mask/udev-181 and  emerge --pretend --update world reports no
> conflicts.
>
> I was about to proceed when I looked at eix udisks and noticed that
> 1. "my" udisk -1.98.0 is no longer there
> 2. The 1-99.0-r1 is now in slot 2 and new 1.0.4-r[23] are in slot 0.
>    I looked at -r3 and it wants >=udev-171-r5.  Since I have -r6 my sys.
>    should meet the requirement.
>
> So I wonder if my mask >=sys-fs/udisks-1.99.0 is a bad idea and I should
> instead be forcing/encouraging udisks-1.0.4-r3 (and, if so, how?).

Not a bad idea per se, but you do realize that you cannoy keep masking
some stuff and upgrading the rest, right? If you are happy with udisks
1.98, get the ebuild /var/db/pkg/sys-fs/udisk-1.98.0 (if still there),
and keep it in a personal overlay. The same with all the stuff you
need for not upgrading udev.

But anyway, this will only work for some time; at some point, it is
possible (and highly probable) that something you need will require
udisks-1.99, or another package that itself requires a newer version
of udev. The only way to avoid the upgrade is to left everything as it
is (don't upgrade), or trying something like Walt's mdev setup:

http://wiki.gentoo.org/wiki/Mdev

Of course, not every software will work with that, contrary to udev.

If you want to force an old version of udev, you will (eventually)
force an old version of everything that depends directly or indirectly
on udev. There is no way around that.

I believe (for reading your posts into the list) that you really don't
want an initramfs, or at least dracut. I would give it a try; I'm
pretty sure is easier than juggling package masks.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Re: [gentoo-user] udev-181 saga continues with udisks (~amd64)

[Allan Gottlieb]

On Sun, Aug 12 2012, Canek Peláez Valdés wrote:

> On Sun, Aug 12, 2012 at 12:47 PM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
>> I have been masking udev-181 so that I can continue to keep my current
>> system with / and /usr separate partitions.
>>
>> This has required masking pciutils and usbutils as well.
>> /etc/portage/package.mask/udev-181 contains
>>   >=sys-fs/udev-181
>>   >=sys-apps/pciutils-3.1.9-r2
>>   >=sys-apps/usbutils-005-r1
>>
>> Now udisks-1.99.0-r1 wants to pull in a new package udev-init-scripts.
>> I currently have udisks-1.98.0 which is fine.
>>
>> I added
>>   >=sys-fs/udisks-1.99.0
>> to package.mask/udev-181 and  emerge --pretend --update world reports no
>> conflicts.
>>
>> I was about to proceed when I looked at eix udisks and noticed that
>> 1. "my" udisk -1.98.0 is no longer there
>> 2. The 1-99.0-r1 is now in slot 2 and new 1.0.4-r[23] are in slot 0.
>>    I looked at -r3 and it wants >=udev-171-r5.  Since I have -r6 my sys.
>>    should meet the requirement.
>>
>> So I wonder if my mask >=sys-fs/udisks-1.99.0 is a bad idea and I should
>> instead be forcing/encouraging udisks-1.0.4-r3 (and, if so, how?).
>
> Not a bad idea per se, but you do realize that you cannoy keep masking
> some stuff and upgrading the rest, right? 

Right.

> If you are happy with udisks 1.98, get the ebuild
> /var/db/pkg/sys-fs/udisk-1.98.0 (if still there), and keep it in a
> personal overlay. The same with all the stuff you need for not
> upgrading udev.
>
> I believe (for reading your posts into the list) that you really don't
> want an initramfs, or at least dracut. I would give it a try; I'm
> pretty sure is easier than juggling package masks.

You are certainly correct that this is a stopgap method.  I am trying to
order a new system from dell and when successful will definitely install
/ and /usr together on one partition and hence have the modern udev.
Once I am comfortably on that new system I will re-install my three old
systems to also have a combined / /usr.  I just don't want to have my
main system down.

thanks,
allan