Re: Conflicts due to renamed KDE4 ports
Am 17.04.18 um 20:29 schrieb Tobias C. Berner: > Moin moin > > Here's a script which should automatically fix the origin for the > kde4-versioned ports (based on the MOVED entries of r465345): > http://people.freebsd.org/~tcberner/scripts/fix_kde4_origins.sh > > It //should// set the origins properly for the moved ports, and the output > should be on the lines of > # ./fix_kde4_origins.sh > [...] > - sysutils/baloo-widgets [sysutils/baloo-widgets-kde4] is not installed. > + Changing origin of nepomuk-core-4.14.3_14 from sysutils/nepomuk-core to > sysutils/nepomuk-core-kde4. > - sysutils/kfloppy [sysutils/kfloppy-kde4] is not installed. > - sysutils/ksystemlog [sysutils/ksystemlog-kde4] is not installed. > + Changing origin of baloo-4.14.3_5 from sysutils/baloo to > sysutils/baloo-kde4. > + Changing origin of kfilemetadata-4.14.3_13 from sysutils/kfilemetadata to > sysutils/kfilemetadata-kde4. > [...] > > > Please let me know if that works for you, or how I could improve it. My suggested version (that does not depend on any hard-coded version strings in the script) is: #!/bin/sh cd /usr/ports for origin in */*-kde4; do origin_old=$(dirname $origin)/$(basename $origin -kde4) pkgname=$(make -C $origin -V PKGNAME) pkg_glob="${pkgname%%.*}.*" package=$(pkg query -g "%n-%v" "$pkg_glob") pkg set -y -o $origin_old:$origin $package done Regards, STefan ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On 17/04/2018 09:11, Tijl Coosemans wrote: On Tue, 17 Apr 2018 00:42:48 +0200 Adriaan de Grootwrote: [where did this discussion take place, earlier? this is the first I've seen it] So, there are roughly two migration paths: supposing someone has x11/kde4 installed, which has dependencies on many applications and a Plasma 4 desktop, kde@ wants (wanted) to make it possible to migrate to a still-KDE4 desktop, while renaming everything to have a -kde4 suffix. The other path is to migrate to the latest-and-greatest-from-KDE .. we don't have a metaport for that, and if we do get one it probably won't be called x11/kde5. For single applications, the migration looks similar: you had, around january 2018, port . That's the KDE4 version. Now there is port -kde4, if you want to stick to KDE4 software (which is no longer released upstream, and is based on an EOL toolkit, but some people feel quite strongly about this). Ports are returning, without a suffix, to mean "the latest-and-greatest- version-of-". This is consistent with other ports which have a , sometimes a -devel for upcoming things, and a - for older versions if you have specific dependencies on old versions. Historically, things were a mess with naming with the KDE ports. We think we've got a good scheme now: -kde4 (and in the far future, -kf5) for versions of the software based on an older stack, and for the current one. But the pain of getting from the mess to something better organized has to happen at some point. What happens when you run pkg upgrade on a 6 months old installation of KDE4? As stated earlier, I had a few kde4-specific applications installed on my system (kwrite, kate, konsole, ...). I am using poudriere and wasn't upgrading for like 6 months. I tried a few weeks ago and it failed. I was getting errors that a file, here listed a path to a file in a new package, is already installed by another package. Deleting the file was leading to another similar error. Manually uninstalling old packages and reinstalling with updated names of course solved the issue but I only had a few of those applications. GrzegorzJ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
Moin moin Here's a script which should automatically fix the origin for the kde4-versioned ports (based on the MOVED entries of r465345): http://people.freebsd.org/~tcberner/scripts/fix_kde4_origins.sh It //should// set the origins properly for the moved ports, and the output should be on the lines of # ./fix_kde4_origins.sh [...] - sysutils/baloo-widgets [sysutils/baloo-widgets-kde4] is not installed. + Changing origin of nepomuk-core-4.14.3_14 from sysutils/nepomuk-core to sysutils/nepomuk-core-kde4. - sysutils/kfloppy [sysutils/kfloppy-kde4] is not installed. - sysutils/ksystemlog [sysutils/ksystemlog-kde4] is not installed. + Changing origin of baloo-4.14.3_5 from sysutils/baloo to sysutils/baloo-kde4. + Changing origin of kfilemetadata-4.14.3_13 from sysutils/kfilemetadata to sysutils/kfilemetadata-kde4. [...] Please let me know if that works for you, or how I could improve it. mfg Tobias On 17 April 2018 at 17:43, Tijl Coosemanswrote: > On Tue, 17 Apr 2018 16:19:39 +0200 Tobias C. Berner wrote: > > Long answer: KDE is shipped in mulitple, let's call them groups: > > - frameworks (libraries to build kde and qt applications) -- we call > > these ports kf5-foo > > - plasma (the desktop) -- we'll call these ports plasma5-foo > > - applications (the applications) > > > > Now, previously during KDE SC4 days, this was a whole "blob". This is why > > it made sense to call them all kde4-foo or foo-kde4. > > Now with this new split there is no real notion to call an application > > foo-kde5. For example during the transition in the last few > > years many KDE Application releases were a mix of Qt4 and Qt5 (i.e. > > kdelibs4 and kf5 based applications). So we would have had > > a kate-kde5 that was using kdelibs-kde4 ... well that would have been > > confusing too. > > > > The same thing will eventually happen when the next KDE Frameworks will > > roll around I expect, where the applications get updated one after > > another, with mixed releases in between. > > > > We opted for the same method as other ports use. A new version appears > that > > is incompatible, move "bar/foo" to "bar/foo3" and update "bar/foo" in > > place. > > I don't think this is the norm. All the big ports (perl, python, php, > gcc, mysql, gtk, qt,...) just leave bar/foo and create bar/foo4. In > place updating to an incompatible version can be a complete surprise > for users (POLA violation) and leave them with a broken system. > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On Tue, 17 Apr 2018 16:19:39 +0200 Tobias C. Berner wrote: > Long answer: KDE is shipped in mulitple, let's call them groups: > - frameworks (libraries to build kde and qt applications) -- we call > these ports kf5-foo > - plasma (the desktop) -- we'll call these ports plasma5-foo > - applications (the applications) > > Now, previously during KDE SC4 days, this was a whole "blob". This is why > it made sense to call them all kde4-foo or foo-kde4. > Now with this new split there is no real notion to call an application > foo-kde5. For example during the transition in the last few > years many KDE Application releases were a mix of Qt4 and Qt5 (i.e. > kdelibs4 and kf5 based applications). So we would have had > a kate-kde5 that was using kdelibs-kde4 ... well that would have been > confusing too. > > The same thing will eventually happen when the next KDE Frameworks will > roll around I expect, where the applications get updated one after > another, with mixed releases in between. > > We opted for the same method as other ports use. A new version appears that > is incompatible, move "bar/foo" to "bar/foo3" and update "bar/foo" in > place. I don't think this is the norm. All the big ports (perl, python, php, gcc, mysql, gtk, qt,...) just leave bar/foo and create bar/foo4. In place updating to an incompatible version can be a complete surprise for users (POLA violation) and leave them with a broken system. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On 17 April 2018 at 14:00, Andriy Gaponwrote: > On 17/04/2018 10:24, Adriaan de Groot wrote: > > So, there are roughly two migration paths: supposing someone has > x11/kde4 > > installed, which has dependencies on many applications and a Plasma 4 > desktop, > > kde@ wants (wanted) to make it possible to migrate to a still-KDE4 > desktop, > > while renaming everything to have a -kde4 suffix. The other path is to > migrate > > to the latest-and-greatest-from-KDE .. we don't have a metaport for > that, and > > if we do get one it probably won't be called x11/kde5. > > > > For single applications, the migration looks similar: you had, around > january > > 2018, port . That's the KDE4 version. Now there is port -kde4, > if > > you want to stick to KDE4 software (which is no longer released > upstream, and > > is based on an EOL toolkit, but some people feel quite strongly about > this). > > Ports are returning, without a suffix, to mean "the > latest-and-greatest- > > version-of-". This is consistent with other ports which have a > , > > sometimes a -devel for upcoming things, and a - for > older > > versions if you have specific dependencies on old versions. > > > > Historically, things were a mess with naming with the KDE ports. We > think > > we've got a good scheme now: -kde4 (and in the far future, > -kf5) for > > versions of the software based on an older stack, and for the > current > > one. But the pain of getting from the mess to something better organized > has > > to happen at some point. > > Moin moin I am just curious why not have explicit -kde4 and -kde5. > I think that qt sets a good example and there is no confusion and no > migration > Short answer: Because there is no kde5 Long answer: KDE is shipped in mulitple, let's call them groups: - frameworks (libraries to build kde and qt applications) -- we call these ports kf5-foo - plasma (the desktop) -- we'll call these ports plasma5-foo - applications (the applications) Now, previously during KDE SC4 days, this was a whole "blob". This is why it made sense to call them all kde4-foo or foo-kde4. Now with this new split there is no real notion to call an application foo-kde5. For example during the transition in the last few years many KDE Application releases were a mix of Qt4 and Qt5 (i.e. kdelibs4 and kf5 based applications). So we would have had a kate-kde5 that was using kdelibs-kde4 ... well that would have been confusing too. The same thing will eventually happen when the next KDE Frameworks will roll around I expect, where the applications get updated one after another, with mixed releases in between. We opted for the same method as other ports use. A new version appears that is incompatible, move "bar/foo" to "bar/foo3" and update "bar/foo" in place. This is not a new thing, it's just a lot in one go, I agree, and I'm sorry for the inconvenience. However, let's not make a problem, that could essentially be solved by a pkg-delete followed by a pkg-add too complicated :) I'll try to create a shell script to rewire the pkg's automatically to the new origin... mfg Tobias pain in the future when 6 appears. > > -- > Andriy Gapon > ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On Tue, 17 Apr 2018 00:42:48 +0200 Adriaan de Grootwrote: > [where did this discussion take place, earlier? this is the first I've seen > it] > > So, there are roughly two migration paths: supposing someone has x11/kde4 > installed, which has dependencies on many applications and a Plasma 4 > desktop, > kde@ wants (wanted) to make it possible to migrate to a still-KDE4 desktop, > while renaming everything to have a -kde4 suffix. The other path is to > migrate > to the latest-and-greatest-from-KDE .. we don't have a metaport for that, and > if we do get one it probably won't be called x11/kde5. > > For single applications, the migration looks similar: you had, around january > 2018, port . That's the KDE4 version. Now there is port -kde4, if > you want to stick to KDE4 software (which is no longer released upstream, and > is based on an EOL toolkit, but some people feel quite strongly about this). > Ports are returning, without a suffix, to mean "the latest-and-greatest- > version-of-". This is consistent with other ports which have a , > sometimes a -devel for upcoming things, and a - for older > versions if you have specific dependencies on old versions. > > Historically, things were a mess with naming with the KDE ports. We think > we've got a good scheme now: -kde4 (and in the far future, -kf5) > for > versions of the software based on an older stack, and for the current > one. But the pain of getting from the mess to something better organized has > to happen at some point. What happens when you run pkg upgrade on a 6 months old installation of KDE4? ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
[where did this discussion take place, earlier? this is the first I've seen it -- oh, the ports@ list] So, there are roughly two migration paths: supposing someone has x11/kde4 installed, which has dependencies on many applications and a Plasma 4 desktop, kde@ wants (wanted) to make it possible to migrate to a still-KDE4 desktop, while renaming everything to have a -kde4 suffix. The other path is to migrate to the latest-and-greatest-from-KDE .. we don't have a metaport for that, and if we do get one it probably won't be called x11/kde5. For single applications, the migration looks similar: you had, around january 2018, port . That's the KDE4 version. Now there is port -kde4, if you want to stick to KDE4 software (which is no longer released upstream, and is based on an EOL toolkit, but some people feel quite strongly about this). Ports are returning, without a suffix, to mean "the latest-and-greatest- version-of-". This is consistent with other ports which have a , sometimes a -devel for upcoming things, and a - for older versions if you have specific dependencies on old versions. Historically, things were a mess with naming with the KDE ports. We think we've got a good scheme now: -kde4 (and in the far future, -kf5) for versions of the software based on an older stack, and for the current one. But the pain of getting from the mess to something better organized has to happen at some point. I think we've been saying this -- that things were going to happen this way -- for nearly a year. Maybe not in all the right places, though. On Monday, 16 April 2018 21:13:29 CEST Tijl Coosemans wrote: > On Mon, 16 Apr 2018 20:11:33 +0200 Stefan Esserwrote: > > Am 16.04.18 um 12:38 schrieb Tijl Coosemans: > >> On Sat, 14 Apr 2018 14:18:22 +0200 Stefan Esser wrote: > >>> The way the new KDE5/KF5 ports have been introduced a few weeks back has > >>> caused me quite some effort (more than 100 hours of work), and now there > >>> have been further changes to implement KDE5 support (which I generally > >>> appreciate), which cause further complications and seem not to be well > >>> thought out. > >>> > >>> These problems affect at least all portmaster users, but I guess > >>> portupgrade is affected as well and a "pkg upgrade" dry-run indicates, > >>> that it will also cause breakage to binary upgrades of KDE4 > >>> installations. > >> > >> Removing entries from MOVED after only a few weeks is a bad idea, but > >> it's not something you have to worry about. As long as portmaster > >> behaves more or less the same as pkg you're good. > > > > I only tried a dry run, but it appears, that pkg does not deal with this > > situation correctly. Grzegorz Junka reported, that it did not work for > > him and he had to manually delete all KDE ports and re-install them from > > his repository built with poudriere. > > > > > > A correct decision is impossible given on the information in the ports. > > > > It is correct to upgrade e.g. databases/akonadi (akonadi-1.13.0_6) to > > databases/akonadi-kde4 (akonadi-kde4-1.13.0_7), but neither the origin > > nor package name nor a MOVED entry provide that information. This is correct if, and only if, you want the migration path of staying-with- KDE4. > > It is not correct to replace databases/akonadi (akonadi-1.13.0_6) by > > databases/akonadi (akonadi-17.12.3), but this can only be seen by > > checking the forward and backward dependencies (which are for KDE5/QT5 > > instead of KDE4/QT4 of the installed port). . and this is the correct move if you want to go with KDE Applications (the current releases). The package manager and the ports-management tools can't know which one you want, I don't think. Consider vim -- it doesn't have one blessed-and-eternal version called "vim", editors/vim is the most-recent version. We've adopted that same convention. What I *do* understand is that the package and ports-management tools don't deal well with this. There was a window where we tried to do all the moving. > > > > The same considerations applied to another port may lead to different > > results. While pkg requires exact dependencies to be installed, it is > > possible to use alternatives to satisfy dependencies with portmaster. > > And this feature is heavily used, e.g. to use a different version of > > samba than the default hard-wired into package dependencies. But this > > flexibility needs a basis for deciding, whether such a replacement is > > valid and how to perform upgrades in that situation. > > > > > > If akonadi is installed only as a dependency of other ports, then pkg will > > install the akonadi-kde4 version. But since the old version is installed > > as an in-use dependency of other KDE4 ports, it will not be removed before > > the installation of the new version is attempted (which will lead to an > > install conflict, since files of an installed port are to be overwritten). > > > > It is possible to
Re: Conflicts due to renamed KDE4 ports
Am 17.04.18 um 00:42 schrieb Adriaan de Groot: > [where did this discussion take place, earlier? this is the first I've seen > it] Hi Adrian, I did not see this being discussed before, just my posts that explain, why portmaster cannopt deal with the simultanous renaming of ports and packages (since it does not recognize the old version to conflict before trying to install the renamed port as a dependency - that was when there were MOVED entries, but portmaster had no logic to lookup by new origin to find the old one and I found it hard to implement a work-around without a complete rewrite of portmaster, which I'm working on for many weeks right now ...) My interest in this issue is as the maintainer of portmaster. I can fix my installed packages by changing the origin woth "pkg set -o" and then have portmaster see the "link" between old and renamed origins and package names. But without such a manual fixup of the pkg registry, portmaster will fail on these ports (abort execution if any of the affected KDE4 ports is part of the work list) and thus it appears to be a portmaster bug. So, I'm looking at this issue not as KDE user, but as portmaster maintainer. > So, there are roughly two migration paths: supposing someone has x11/kde4 > installed, which has dependencies on many applications and a Plasma 4 > desktop, > kde@ wants (wanted) to make it possible to migrate to a still-KDE4 desktop, > while renaming everything to have a -kde4 suffix. The other path is to > migrate > to the latest-and-greatest-from-KDE .. we don't have a metaport for that, and > if we do get one it probably won't be called x11/kde5. Yes, and the least I had expected was an entry in UPDATING, with commands to execute on such a system to migrate to a state as if it had been installed after the renaming of the KDE4 ports and packages, e.g.: Execute the following commands to migrate your installed KDE4 packages to make them consistent with the renamed KDE4 ports: pkg set -y -o databases/akonadi:databases/akonadi-kde4 -g "akonadi-1.*" pkg set -y -o graphics/okular:graphics/okular-kde4 -g "okular-4.* ... As far as I'm concerned, it is not required that the package names are adjusted, since that will correctly happen, if the registered port origins are pointing at the locations used in DEPENDS entries. BTW: Since akonadi-1.* and akonadi-17.* conflict with each other, it is not possible to install any KF5 port that depends on akonadi in parallel to any KDE4 port that depends on akonadi-kde4. I have not checked whether this prevents parallel installation of the KDE4 and KDE5 desktops, but it will cause further problems, if there are any installed ports that need the old version and any KF5 ports that have (direct or indirect) dependencies on the akonadi-17.*, but it is likely to cause portmaster to fail, since it cannot know how to deal with that conflict. (Such conflicts are typically for ports like samba for which many versions exist, that are mostly inter-changeable from the point of view of view of ports that just require any samba server version to be installed. The typical logic in portmaster is to keep such conflicting versions, instead of replacing them with the exact version specified as a dependency., but that will make portmaster try to build KF5 programs with akonadi-kde4, if that happens to be installed at that time.) > For single applications, the migration looks similar: you had, around january > 2018, port . That's the KDE4 version. Now there is port -kde4, if > you want to stick to KDE4 software (which is no longer released upstream, and > is based on an EOL toolkit, but some people feel quite strongly about this). > Ports are returning, without a suffix, to mean "the latest-and-greatest- > version-of-". This is consistent with other ports which have a , > sometimes a -devel for upcoming things, and a - for older > versions if you have specific dependencies on old versions. Yes, and there's nothing wrong with this approach in general, IMHO. But in the case of a framework with many inter-dependent packages as is the case for KDE, such a renaming has a large chance of introducing inconsistencies. As I said before: If the KDE4 ports had not been changed with regard to port origin and package name at the time, port management tools had a chance to detect the connection between old and new names. But with both changed and no MOVED entries (because of the new KDE5 versions of the ports), there is no basis for a decision (but the conflict will be detected and has to be manually fixed by deleting the old version to allow the renamed version to install). > Historically, things were a mess with naming with the KDE ports. We think > we've got a good scheme now: -kde4 (and in the far future, -kf5) > for > versions of the software based on an older stack, and for the current > one. But the pain of getting from the mess to something better organized has > to happen at some point. The scheme looks
Re: Conflicts due to renamed KDE4 ports
Am 16.04.18 um 21:13 schrieb Tijl Coosemans: > On Mon, 16 Apr 2018 20:11:33 +0200 Stefan Esserwrote: >> When not even pkg can deal with this situation, how should portmaster? >> >> The packages are built without consideration for the requirements of a >> running system, and pkg sees all the meta-information of all installed >> packages and the one being processed and can e.g. see, that files will >> conflict (which portmaster can only do after completely building the >> port, which means that this is long after the decision to use that port >> has been required). >> >> >> The lack of consideration given by port maintainers is quite frustrating, >> since it requires a lot of effort to work around the issues caused. > > Like I said, IMHO it's not your problem, so you don't need to work around > it and you don't have to feel frustrated by it. Without an entry in MOVED > there's no way for portmaster or pkg to know that the old akonadi needs to > be replaced with akonadi-kde4. If any user contacts you about this you > can forward them to kde@ because they created the problem. > > IMHO, entries in MOVED should stay for at least a year, if not several > years, so kde@ should restore the kde4 MOVED entries and give the kde5 > ports a -kde5 suffix or something. Hopefully there aren't that many users > yet because you can't create MOVED entries for this move. Seems that I misunderstood your reply ... Yes, adding -kde5 to all ports that have got origins previously used for KDE4 ports, and MOVED entries for those KDE4 ports would solve the issue. It would have helped, if either port origin or package name of the KDE4 ports had been kept, since that would have allowed to link the ports and packages over the change by the unchanged attribute. The absolute minimum would have been a complete set of "pkg set -o" commands to adjust the registered origins of all affected and installed KDE4 ports in an UPDATING entry. I'm not sure that poudriere can create packages that let pkg upgrade succeed without file conflicts, unless the relation is revealed by the MOVED entries. So, I agree with your proposal (previously also suggested by me) of MOVED entries for the KDE4 ports and new non-conflicting origins for those KDE5 ports that re-use the previous KDE4 origins (obviously without MOVED entries, but since the package names (without the version) remain unchanged for those KDE5 ports, automatic port and package upgrades can work for them. Regards, STefan ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On Mon, 16 Apr 2018 20:11:33 +0200 Stefan Esserwrote: > Am 16.04.18 um 12:38 schrieb Tijl Coosemans: >> On Sat, 14 Apr 2018 14:18:22 +0200 Stefan Esser wrote: >>> The way the new KDE5/KF5 ports have been introduced a few weeks back has >>> caused me quite some effort (more than 100 hours of work), and now there >>> have been further changes to implement KDE5 support (which I generally >>> appreciate), which cause further complications and seem not to be well >>> thought out. >>> >>> These problems affect at least all portmaster users, but I guess portupgrade >>> is affected as well and a "pkg upgrade" dry-run indicates, that it will also >>> cause breakage to binary upgrades of KDE4 installations. >> >> Removing entries from MOVED after only a few weeks is a bad idea, but >> it's not something you have to worry about. As long as portmaster >> behaves more or less the same as pkg you're good. > > I only tried a dry run, but it appears, that pkg does not deal with this > situation correctly. Grzegorz Junka reported, that it did not work for > him and he had to manually delete all KDE ports and re-install them from > his repository built with poudriere. > > > A correct decision is impossible given on the information in the ports. > > It is correct to upgrade e.g. databases/akonadi (akonadi-1.13.0_6) to > databases/akonadi-kde4 (akonadi-kde4-1.13.0_7), but neither the origin > nor package name nor a MOVED entry provide that information. > > It is not correct to replace databases/akonadi (akonadi-1.13.0_6) by > databases/akonadi (akonadi-17.12.3), but this can only be seen by > checking the forward and backward dependencies (which are for KDE5/QT5 > instead of KDE4/QT4 of the installed port). > > The same considerations applied to another port may lead to different > results. While pkg requires exact dependencies to be installed, it is > possible to use alternatives to satisfy dependencies with portmaster. > And this feature is heavily used, e.g. to use a different version of > samba than the default hard-wired into package dependencies. But this > flexibility needs a basis for deciding, whether such a replacement is > valid and how to perform upgrades in that situation. > > > If akonadi is installed only as a dependency of other ports, then pkg will > install the akonadi-kde4 version. But since the old version is installed > as an in-use dependency of other KDE4 ports, it will not be removed before > the installation of the new version is attempted (which will lead to an > install conflict, since files of an installed port are to be overwritten). > > It is possible to manually and forcefully delete akonadi-1.13.0_6 before > starting pkg upgrade for the KDE4 ports that depend on it. In that case, > there is no conflict. But pkg autodelete cannot be used, since to remove > the dependency on the old version, the (conflicting) new version must be > registered in the ports that depend on akonadi. > > If akonadi has been directly installed and not (only) as a dependency, > the akonadi-17.12.3 will be considered to be an upgrade of akonadi-1.13.* > (same origin and same package name, except for the version numbers). This > will remove the required dependency from the KDE4 ports and will register > the KDE5 version as new dependency of those ports (although it completely > useless in that role). > > > When not even pkg can deal with this situation, how should portmaster? > > The packages are built without consideration for the requirements of a > running system, and pkg sees all the meta-information of all installed > packages and the one being processed and can e.g. see, that files will > conflict (which portmaster can only do after completely building the > port, which means that this is long after the decision to use that port > has been required). > > > The lack of consideration given by port maintainers is quite frustrating, > since it requires a lot of effort to work around the issues caused. Like I said, IMHO it's not your problem, so you don't need to work around it and you don't have to feel frustrated by it. Without an entry in MOVED there's no way for portmaster or pkg to know that the old akonadi needs to be replaced with akonadi-kde4. If any user contacts you about this you can forward them to kde@ because they created the problem. IMHO, entries in MOVED should stay for at least a year, if not several years, so kde@ should restore the kde4 MOVED entries and give the kde5 ports a -kde5 suffix or something. Hopefully there aren't that many users yet because you can't create MOVED entries for this move. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
Am 16.04.18 um 12:38 schrieb Tijl Coosemans: > On Sat, 14 Apr 2018 14:18:22 +0200 Stefan Esserwrote: >> The way the new KDE5/KF5 ports have been introduced a few weeks back has >> caused me quite some effort (more than 100 hours of work), and now there >> have been further changes to implement KDE5 support (which I generally >> appreciate), which cause further complications and seem not to be well >> thought out. >> >> These problems affect at least all portmaster users, but I guess portupgrade >> is affected as well and a "pkg upgrade" dry-run indicates, that it will also >> cause breakage to binary upgrades of KDE4 installations. > > Removing entries from MOVED after only a few weeks is a bad idea, but > it's not something you have to worry about. As long as portmaster > behaves more or less the same as pkg you're good. I only tried a dry run, but it appears, that pkg does not deal with this situation correctly. Grzegorz Junka reported, that it did not work for him and he had to manually delete all KDE ports and re-install them from his repository built with poudriere. A correct decision is impossible given on the information in the ports. It is correct to upgrade e.g. databases/akonadi (akonadi-1.13.0_6) to databases/akonadi-kde4 (akonadi-kde4-1.13.0_7), but neither the origin nor package name nor a MOVED entry provide that information. It is not correct to replace databases/akonadi (akonadi-1.13.0_6) by databases/akonadi (akonadi-17.12.3), but this can only be seen by checking the forward and backward dependencies (which are for KDE5/QT5 instead of KDE4/QT4 of the installed port). The same considerations applied to another port may lead to different results. While pkg requires exact dependencies to be installed, it is possible to use alternatives to satisfy dependencies with portmaster. And this feature is heavily used, e.g. to use a different version of samba than the default hard-wired into package dependencies. But this flexibility needs a basis for deciding, whether such a replacement is valid and how to perform upgrades in that situation. If akonadi is installed only as a dependency of other ports, then pkg will install the akonadi-kde4 version. But since the old version is installed as an in-use dependency of other KDE4 ports, it will not be removed before the installation of the new version is attempted (which will lead to an install conflict, since files of an installed port are to be overwritten). It is possible to manually and forcefully delete akonadi-1.13.0_6 before starting pkg upgrade for the KDE4 ports that depend on it. In that case, there is no conflict. But pkg autodelete cannot be used, since to remove the dependency on the old version, the (conflicting) new version must be registered in the ports that depend on akonadi. If akonadi has been directly installed and not (only) as a dependency, the akonadi-17.12.3 will be considered to be an upgrade of akonadi-1.13.* (same origin and same package name, except for the version numbers). This will remove the required dependency from the KDE4 ports and will register the KDE5 version as new dependency of those ports (although it completely useless in that role). When not even pkg can deal with this situation, how should portmaster? The packages are built without consideration for the requirements of a running system, and pkg sees all the meta-information of all installed packages and the one being processed and can e.g. see, that files will conflict (which portmaster can only do after completely building the port, which means that this is long after the decision to use that port has been required). The lack of consideration given by port maintainers is quite frustrating, since it requires a lot of effort to work around the issues caused. Regards, STefan ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On Sat, 14 Apr 2018 14:18:22 +0200 Stefan Esserwrote: > The way the new KDE5/KF5 ports have been introduced a few weeks back has > caused me quite some effort (more than 100 hours of work), and now there > have been further changes to implement KDE5 support (which I generally > appreciate), which cause further complications and seem not to be well > thought out. > > These problems affect at least all portmaster users, but I guess portupgrade > is affected as well and a "pkg upgrade" dry-run indicates, that it will also > cause breakage to binary upgrades of KDE4 installations. Removing entries from MOVED after only a few weeks is a bad idea, but it's not something you have to worry about. As long as portmaster behaves more or less the same as pkg you're good. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On Sat, 14 Apr 2018 19:53:49 +0200, Stefan Esser stated: >Yes, but I put literally hundreds of hours of effort into >understanding portmaster (which is one monolythic 4000 line >shell script with global state that recursively invokes itself >to implement local state, with hundreds of instances forked in >practice) and implementing FLAVOR support. Good luck. A 4,000+ line shell script is, IMHO, ridiculous. -- Carmel ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
Am 14.04.18 um 18:57 schrieb Steve Kargl: > On Sat, Apr 14, 2018 at 02:30:09PM +, Carmel NY wrote: >> On Sat, 14 Apr 2018 14:18:22 +0200, Stefan Esser stated: >> >> {truncated} >> >>> This is another case (after the implementation of FLAVOR support that does >>> not seem well-designed and causes lots of effort and inefficiencies in port >>> management tools like portmaster), which makes me consider giving up my >>> efforts to keep portmaster alive. >> >> Have you tried using "synth"? > > This discussion occurred with the introduction of FLAVORS, > which broken all ports management tools except poudriere. Yes, but I put literally hundreds of hours of effort into understanding portmaster (which is one monolythic 4000 line shell script with global state that recursively invokes itself to implement local state, with hundreds of instances forked in practice) and implementing FLAVOR support. That worked, until the next breakage was introduced by port and package renames, that make it impossible to automatically track the history of a port and to upgrade it correctly. While poudriere just rebuilds ports (using available packages to satisfy dependencies) and does not care what dependencies a user has previously used on a system (e.g. which of multiple SSL libraries, for ports that offer a choice). Instead the packages built by poudriere will enforce a certain set of dependencies, giving the user no choice (unless the packages were custom built with specific options). But it seems that the packages built by poudriere are also not suitable for a clean upgrade of installed KDE4 ports. At least in a test run, some 10 KF5 ports were going to be installed during an attempt to upgrade a KDE4 port from an official package. Portmaster was fully functional before this new breakage, and I'm really annoyed, that the KDE port and package name changes have been performed without any thought about the consequences for port management tools. It is possible to work around this problem by manually setting certain parameters in the package DB for each affected port. I had expected that at least a script that perform these operations on the package DB was provided. Now the best option appears to be to remove all installed KDE4 ports and then to rebuild them with portmaster (which will work, but requires a lot of unnecessary effort and time). I'm still trying to find a satisfactory heuristic that lets portmaster DTRT. But this is a problem, since there are situations where one choice of action is correct, while it will lead to corruption of the installed packages in other cases. The problem is, that now there are systems that have KDE4 ports with package names (sans version) and origin identical to KDE5 versions of the respective program (e.g. databases/akonadi used to be a KDE4 port that built akonadi-1.*, now it is a KDE5 port that builds akonadi-17.*, which is of no use on a KDE4 system and not suitable for use with KDE4 ports. Upgrading akonadi (and the tens of other KDE4 ports whose port directory has been hijacked by KDE5 versions) will thus create useless KDE5 versions (and the KDE4 version will be removed when the KDE5 version is installed). Later upgrades of ports that depend on akonadi-kde4 will install the correct new dependency (but are broken up to that point). But the useless KDE5 ports will not be automatically removed. Hmmm, if they were installed as an automatic dependency (and not directly by the user), I could use that as a sign, that no other port depends on them (unless they are actually required by a KDE5 package). This will require extra effort, but I can try whether this works reliably. I'll see whether I find an algorithm that uses information not currently required or used to resolve these cases. But this will only be in a completely new portmaster, which shares just the options processing (to stay as compatible as possible with existing scripts that invoke it) with the current version in ports. Regards, STefan ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On Sat, Apr 14, 2018 at 10:12 AM, Carmel NYwrote: > On Sat, 14 Apr 2018 09:57:07 -0700, Steve Kargl stated: > > >This discussion occurred with the introduction of FLAVORS, > >which broken all ports management tools except poudriere. > > So, you have not tried "synth" and I assume poudriere. > Please STOP! He is the maintainer of portmaster and, for many people, portmaster is still a critical system component that is not replaceable by either synth or poudriere. Since his goal is to make portmaster work, telling him that he should use another tool is missing the whole point. The issue he is bringing up is NOT flavors. portmaster has supported flavors for some time. It is changes made to a set of ports that seems to break the existing paradigm of the ports system. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On Sat, 14 Apr 2018 09:57:07 -0700, Steve Kargl stated: >This discussion occurred with the introduction of FLAVORS, >which broken all ports management tools except poudriere. So, you have not tried "synth" and I assume poudriere. -- Carmel ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On Sat, Apr 14, 2018 at 02:30:09PM +, Carmel NY wrote: > On Sat, 14 Apr 2018 14:18:22 +0200, Stefan Esser stated: > > {truncated} > > >This is another case (after the implementation of FLAVOR support that does > >not seem well-designed and causes lots of effort and inefficiencies in port > >management tools like portmaster), which makes me consider giving up my > >efforts to keep portmaster alive. > > Have you tried using "synth"? This discussion occurred with the introduction of FLAVORS, which broken all ports management tools except poudriere. -- Steve ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On 14/04/2018 12:18, Stefan Esser wrote: [cut] This is another case (after the implementation of FLAVOR support that does not seem well-designed and causes lots of effort and inefficiencies in port management tools like portmaster), which makes me consider giving up my efforts to keep portmaster alive. STefan This caused some headache on my system too even though I use poudriere to build packages and I don't use the whole kde suite, just some applications. I had to manually uninstall all old kde ports and re-install them again adding the kde4 suffix. Are you saying I will need to do that again when I want to switch to kde5? I haven't seen any consultation being posted on this forum if/when/how the introduction of kde5 should be handled. I imagine it's not the first time such a massive upgrade of version has had happened in FreeBSD ports. Is it how it's usually handled? Also, wouldn't in this case converting kde to flavours, i.e. kde-base@kde4 and kde-base@kde5 be a better approach? GrzegorzJ ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Conflicts due to renamed KDE4 ports
On Sat, 14 Apr 2018 14:18:22 +0200, Stefan Esser stated: {truncated} >This is another case (after the implementation of FLAVOR support that does >not seem well-designed and causes lots of effort and inefficiencies in port >management tools like portmaster), which makes me consider giving up my >efforts to keep portmaster alive. Have you tried using "synth"? I have not used it on KDE since I don't have KDE installed; however, it has worked well with other ports that seemed to have a similar problem. It couldn't hurt to give it a try. Just make sure you have an up-to-date ports tree before running it. -- Carmel ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"