<SiFuh>
Someone at google must have been bored ;-)
<ukky>
farkuhar: Does http://ix.io/4s0B fix the warning from FS#15 description? I.e. an attempt to 'rmdir /usr/var/' vs 'rm /usr/var'
<farkuhar>
ukky: No, it doesn't. Back to the drawing board. ;-)
<ukky>
should we split FS#15 into two bugs?
<farkuhar>
One bug when removing a package that uses legacy paths, and another bug when upgrading a package that has rearranged its footprint with backward-compatible symlinks?
<farkuhar>
I agree; the two issues are distinct. It was the comment by jue on 20130405 that inspired my approach of using 'realpath' to compare old and new footprints. Different logic is probably needed when removing a package.
<farkuhar>
It might be easier to resolve FS#1074 first. If the patch I posted there is merged, then we'll be starting from a new baseline, with a three-argument db_rm_pkg instead of the current two-argument variant.
<ukky>
'realpath' should be used dealing with children of symlink'ed directory. This will properly map files to real file system content.
<ukky>
But symlink itself should be dealt with separately, without 'realpath' resolution.
<ukky>
Not sure yet, but it could be that -every- symlink'ed directory should not be resolved via 'realpath', only files under that directory.
<farkuhar>
I think you're onto something there. Off the top of my head, however, I can't remember all the data structures that are available in db_rm_pkg, to distinguish whether the target of a symlink is a directory or a regular file. Will have to investigate further.
<ukky>
I have mixed thoughts with regard to FS#1074. It seems more logical to me to uninstall a file that is not available anymore in the updated port.
<farkuhar>
Uninstalling the outdated file is actually what will happen in most cases. The issue in FS#1074 is that users expect their "UPGRADE NO" directives to be respected, and they won't be too happy about an automatic deletion of, say, a customized config that has no counterpart in the newer version of the package (or whose counterpart in the new version has been renamed).
<ukky>
Still, mixed thoughts. I see benefits in both fixing FS#1074, and closing FS#1074 with a resolution 'this is an intended feature'
<farkuhar>
Better to close a bug report with 'this is an intended feature' than with 'nobody wants to implement this'. When the latter resolution was applied to FS#1843, that ticket disappeared from the front page. If beerman had left it in place, I would never have bothered to open FS#1910.
<farkuhar>
But if we don't merge any of the proposed patches for FS#1074, and close the ticket with 'this is the intended behaviour', then sooner or later someone will rediscover the phenomenon that their UPGRADE NO directives are being ignored, and they'll open a duplicate ticket (cf #1843 and #1910). Rather than clutter the Flyspray db, it's easier just to leave the current ticket open.
<ukky>
Resolving FS#1074 requires making a decision: Do we want to 'keep it simple' and just document the corner cases of the port update/upgrade process, or do we implement the most intelligent pkgutils ever made? I am good with both decisions, and willing to contribute in any field where my experience might be helpful. Just expressing my opinion, as I do not have voting power in here.
groovy3shoes has joined #crux
groovy2shoes has quit [Ping timeout: 260 seconds]
lavaball has quit [Remote host closed the connection]
<farkuhar>
Those who do have voting power are not in the habit of exercising it until there's enough interest expressed by the CRUX userbase. Just by keeping the discussion alive, ukky is helping advance us to the point where an actual vote might happen.
<farkuhar>
Where you stand on the issue of FS#1074 stems from what you value higher: is it more important that our tools behave uniformly in all situations (eschewing any "auto-magic" interaction between CLI flags), or that they avoid the worst-case outcome like unexpected data loss (even if that is how a KISS implementation would work)?
<nekobit>
farkuhar: I used an f-droid maps app and it drove me straight into a wall
<nekobit>
farkuhar: I think Gentoo had an actual structure for handling major file changes like this
<nekobit>
looking at 1074
<nekobit>
you actually run a different command entirely to do these changes, but i could be wrong, i mainly ever saw it done to portage itself, it probably had commands to handle file changes too though
<nekobit>
this may come helpful to see how it handles file overwrites?
<nekobit>
and basically, if you "protect" config files, then if say, portage requests to delete said file (or poke it, really, is what etc does), you can do additional changes such as merge them
<SiFuh>
A dump folder would be better
<ukky>
We can add another use case into discussion. When user have 'UPGRADE NO' protection for a file(set) in ^etc, and decides to uninstall the port, all protected files will be lost. And yes, I know that 'UPGRADE' does not protect from file removal upon uninstall.
<nekobit>
i think a good way to approach it is when doing an "install", check certain files, see if they diff (compare hashes?), then do something
<SiFuh>
The point is the file is not needed anymore or has a new name. If it has a new name, then I think the maintainer is now responsible for this. If the file is gone forever then if the user wishes to save it for other purposes then create a a /var/dump/ or some shit.
<nekobit>
it weird cases you can back them up
<nekobit>
i think debian or something does this
<SiFuh>
I do understand where those who are upset about losing newly _OLD_ config files are coming from. It's a lot of work you want saved, maybe for something else
<SiFuh>
When a package manager just carelesly obliterates it form existance, that cold hearted package manager. You want to kill whom ever is repsonsible for the callousness
<SiFuh>
form/from*
<ukky>
In a perfect design, pkgutils should compare file(s) being removed with original from foo-OLD-VERSION.pkg.tar.gz and if they are different, place them into /var/lib/pkg/removed/, and then admin can resurrect those files if needed
<SiFuh>
ukky: Did I miss read the actual topic?
<ukky>
This makes pkgutils more complex, but might make users happy
<SiFuh>
If the file no longer exists then compare it to what?
<SiFuh>
If the file changed names like mc.ext to mc.ext.ini then compare it to what?
<SiFuh>
I feel the maintainer should know this one and not touch the old one. mc.ext to mc.ext.ini
<ukky>
SiFuh: FS#1074 raises this issue. Old version of port might have mc.ext, but new version installs mc.ext.ini
<ukky>
Thus, user will loose mc.ext upon port upgrate
<SiFuh>
And if mc.ext is not moved/renamed and is no longer needed. Then dump it in your /var/lib/pkg/removed/
<ukky>
Moving user-modified file to /var/lib/pkg/removed/ is just an idea
<SiFuh>
And not a good one, because I don't want everything I have modified in there
<SiFuh>
But I see what you are trying to do
<SiFuh>
It's a good start for the minds to juggle ideas though.
<ukky>
If upon upgrade pkgutils just deletes mc.ext, inexperient user might not be happy
<SiFuh>
I would not for sure. My mc.ext was years of work
<ukky>
That is what we are discussing today
<SiFuh>
I think that particular scenario should be upt to the maintainer
<SiFuh>
When the file is no longer needed (NOT renamed) it should be saved as a backup in some dump directory
<ukky>
Pkgutils do not know if file is renamed or deleted
<SiFuh>
Pkgutils doesn't know much, it is kind of outdated
<SiFuh>
Maybe CRUX needs a complete re-write?
<SiFuh>
Chuck in a heap of mods, but still keep it simple
<SiFuh>
An idiea would be to merge Pkgutils with prt-get
<SiFuh>
I wonder if Pkgutils has served us long enough
<ukky>
My non-powerful vote goes for keeping pkgadd, pkgmk, and pkgrm as separate, standalone tools, doing just one task.
<ukky>
Is there any way to recover initial source code for pkgutils port?
<farkuhar>
ukky: the "initial commit" in the git history of tools/pkgutils is probably a snapshot from the subversion -> git transition. Unless you have access to the old subversion repo, the best you can do is clone git://crux.nu/tools/pkgutils.git and go back to the initial commit.
lavaball has joined #crux
<cruxbot>
[opt.git/3.7]: qtwebengine: fixed build if re2 is installed
lavaball has quit [Remote host closed the connection]
<farkuhar>
at the time of that thread, Anton and others had been working privately on their own rewrites of pkgutils (mostly in C). The thread on FS#15 and #63 (July 2006) alluded to a rewrite called pkgutils-ng, for example.