With 1.3 the overlay directoy is changed from /usr/local/portage/layman to /var/lib/layman. This happens silently without informing the user via einfo. It also sucks for everybody who already has a couple of overlays installed which suddenly don't get updated anymore. It would be nice to be informed about that move PROMINENTLY. Also layman should honor PORTAGE_OVERLAY and not create a second layman overlay directory without asking - and if it does, at least it should honor already installed overlays in /usr/local/portage/layman and not ignore them silently. Reproducible: Always
To get the new config file you had to run etc-update or one of its alternatives. At that moment you either blindly continued or noticed what to do and failed to act accordingly. I really don't see how anything more is necessary here. Rejecting storage locations different to those used in PORTAGE_OVERLAY does not seem to be adequate to me. So I'm closing this as "INVALID". I don't do that often or easily, I really do think it fits here.
sigh* I got the new config files. Which is part of the problem, because there are no overlays in /var/lib/layman. All the stuff was in /usr/local/portage/layman. I only realized that there was a problem when strigi failed because it was still in the old kde overlay. This bug is not INVALID. You failed to inform about the change. EINFO and NEWS are there for a reason. A news message to warn about the change would have been apropriate. Running into this mess and then being screwed over because 1.3.2 is broken is no fun at all.
(In reply to comment #2) > sigh* I got the new config files. > > Which is part of the problem, because there are no overlays in /var/lib/layman. > All the stuff was in /usr/local/portage/layman. right. you have to decided for either and move stuff as needed. that's not too hard in my eyes. > You failed to inform about the change. EINFO and NEWS are there for a reason. A > news message to warn about the change would have been apropriate. Running into > this mess and then being screwed over so if that extra message could have helped: sorry. > because 1.3.2 is broken is no fun at all. how is 1.3.2 broken? are you referring to bug #306143? have you checked out 1.3.2-r1?
yes, but I when -r1 came I already had created the make.conf entries by hand. that message would have helped A LOT. No fun to find out by accident that layman is using a different directory now. And I am sure that I am not the only one who will be caught by this going from 1.2.X to 1.3. A NEWS message would at least have a chance to get noticed.
(In reply to comment #4) > A NEWS message would at least have a chance to get noticed. I have prepared a news item and proposed it to gentoo-dev. Further actions depend on the feedback I receive from fellow developers.
thank you. I just realized that I sounded very obnoxious. That was not intended.
I think it was within the okay range :-) The mail hit the archives by now, it's up here: http://archives.gentoo.org/gentoo-dev/msg_28efc1f9f6527b772f4cd9761b78a11b.xml If you have ideas on how to improve the proposed item please either write to gentoo-dev or to me directly.
News item added, closing.
since 1.3 is still not keyworded, perhaps you should put a einfo note in the postinstall for users who are upgrading to read that archived news item. I'm sure others and myself will forget about the change once it's keyworded and someone is bound to open another ticket on it. It would save time bu just putting a 2 line note: Users who are upgrading from 1.2.x Please see the following new item: # eselect news read 2010-02-28-layman-storage-path-change
well apparently news can't reference the new items by title only by index. It also wouldn't work for users who have installed gentoo after today. I believe new items are not downloaded retroactively. For instance I have 2007-05-04-paludis-0.24 in my /usr/portage/metadata/news but it doesn't show up in my "eselect news list" output If there are web archives of the news item, I'd link to that instead.
(In reply to comment #9) > since 1.3 is still not keyworded Not keyworded for what? http://znurt.org/app-portage/layman (In reply to comment #10) > For instance I have 2007-05-04-paludis-0.24 in my /usr/portage/metadata/news but it doesn't show up in my "eselect news list" output If you don't have paludis installed that's expected. The line Display-If-Installed: <sys-apps/paludis-0.30 in there makes it hidden. Back to your original request: I'm unsure if I should add such info. Maybe I'm just to lazy and don't see a real need :-) Fauli, what do you say?
(In reply to comment #11) > Back to your original request: I'm unsure if I should add such info. > Maybe I'm just to lazy and don't see a real need :-) Fauli, what do you say? What is the original request? Is it for people that update in some months to layman 1.3? Reissuing the news item upon stabilisation should be a good idea. My though about news items is to warn stable users only for most news items...testing users should figure it out themselves.
Thanks for the warning (news item). I actually rejected the last path change, and still use /usr/portage/local/layman/ (which still seems more natural to me). :)
