Dan Cîrnaț <cirnatdan%NetBSD.org@localhost> writes: >> Do you believe that over the next 5 years we will be able to have just >> one version of gnome-ish things, named simply gnome with no version in >> the name? > > Yes. I can't speak for the GNOME project, but I don't see any reason to > expect otherwise. > > There might arise a need to keep some old versions like it is done for > firefox78, firefox68 and so on. I don't think this would be worth > the effort though. I imagine that users who can't always run the > latest GNOME have already switched to an alternative. That sounds good enough. The idea is to avoid flipping back and forth between "we only need one version of Foo" and "we need FooN and FooM" more than once every 5 years. My cynical view is that once an upstream has behaved in such a way that we need to have multiple versions, that's likely to continue. But here, after the gnome2->3 switch, it's just been gnome, so the ancient history is discountable. >> So when 41 comes out, we maybe put it in wip, we wait until >> someone (you?) decides that it works well enough, and then some time >> earlyish in the branch cycle just update? > > Don't know how to answer this. I'm still new to NetBSD development so > I'm not sure what QA process would be best. Sorry, I didn't mean to be prescriptive about wip. What I meant is: Do you envision that when 41 comes out, someone like you can decide "yes, it's time to update" and we just update the packges from 40 to 41, and there is no thought of "but we need to import gnome40 versions of these 4 things because X depends on it and X doesn't work with 41". >> It sounds like you are saying that there will be no gnome 3.x in >> pkgsrc any more. everything will be updated to a 40.x series. > > Yes, because the 40.x series is just a renamed 3.40.x. At least that's > how Linux distros are packaging 40.x. [1][2] Wow, that's funny. But sounds fine. >> Does gnome have a plan for API compat that makes updating the core >> while not breaking any even slightly maintained thing that depends on >> the core? (Or, equivalently, do you think it's in the interest of >> users to let anything that is broken by Gnome API "progress" just be >> demoted to wip as crufty and unmaintained?) > > The new naming scheme only affects high-level applications and unstable > libraries that shouldn't be used outside of GNOME.[0] GLib, GTK and > other core libraries are staying with semver, there is no need to > rename those. > Unless someone still uses gdm-2.x from pkgsrc, no other application is > being removed or demoted. So it sounds like a first step is a removal proposal for all the gnome2 bits that are in the way naming size. (Not a big deal, just "I intend to remove after a week" on pkgsrc-users, with your explanation for why you believe ~nobody is using them.) >> What happens to apps that are built against gtk3, and the gtk3 version >> of the desktop library? And for whcih there is no release that can >> use gtk4/gnome-desktop/40? Will they still be buildable within >> pkgsrc? (Maybe this question is confused and there is API compat; >> that would be great.) > > In case of GTK3, GTK4 - these should keep the current name. gnome- > desktop-40 and other GNOME40 components still depends on GTK3, in fact. > One of the reasons for the new naming scheme is to decouple the GTK > development cycle from the "GNOME desktop" development cycle. Multiple > version of GTK will continue to exist in parallel.[0] > "gnome-desktop", on the other hand, is an "unstable" collection of code > used by GNOME apps and should be updated together with the rest of the > desktop components.[3] That's fine then. What I was worried about is things that are less maintained having to use old verisions of gnome we no longer have and that leading to needing multiple versions. >> I gather gnome2 is really no longer existing (even though mate exists >> - but it it is no longer called gnome). (But what about >> x11/py-gnome2?) > > x11/py-gnome2 and other GNOME2 leftovers, if any, can be kept and > coexist as long as they are needed. I had no plans to touch them. OK. >> Is gnome-desktop (2.x) a candidate for removal (as unmaintained and we >> believe there are essentially no users) in its own right? I would >> have thought so, vs gnome2-world things use mate-destkop, but >> finddepends on it prints out a lot of things. Are they going to work >> with gnome-desktop 40, at least as well as they worked with the old >> gnome2 version? (It may be that gnome-desktop(2) is a separate >> historical mess to be cleaned up first.) > > gnome-desktop(2.x) seems like a candidate for removal to me. Aside from > some wip packages, the only mentions in the main pkgsrc should be > cleaned up. Only GNOME components need to depend on gnome-desktop, and > most of those are already updated to the 3.x versions. So probably that should happen as well, along with the earlier removal, before you do the rename. finddepends x11/gnome-desktop shows me rather a lot. (It's not necessary to take care of wip, but most of this isn't wip.) devel/compizconfig-backend-gconf/Makefile devel/libcompizconfig/Makefile devel/py-compizconfig/Makefile fonts/gnome-font-viewer/Makefile graphics/cheese/Makefile graphics/eog/Makefile mail/evolution/buildlink3.mk multimedia/totem/Makefile sysutils/gnome-control-center/Makefile sysutils/gnome-font-viewer/Makefile sysutils/gnome-settings-daemon/Makefile sysutils/nautilus/Makefile wip/contacts/Makefile wip/dates/Makefile wip/desktop-data-model/Makefile wip/emerald/Makefile wip/libslab/Makefile wip/libslab/buildlink3.mk wm/compiz-fusion-plugins-extra/Makefile wm/compiz-fusion-plugins-main/Makefile wm/compiz/buildlink3.mk wm/compiz/options.mk wm/mutter/Makefile x11/gnome-desktop/buildlink3.mk x11/gnome-desktop3/buildlink3.mk x11/gnome-session/Makefile x11/gnome-shell/Makefile So I'm not sure of the way forward here, but I hope you can see a good path!
Attachment:
signature.asc
Description: PGP signature