[gentoo-dev] Re: News item review: SquashDelta syncing support
Brian Dolbec dol...@gentoo.org wrote: Martin Vaeth mar...@mvath.de wrote: However, currently this does not play nicely with squashdelta: You have to undo the mounting of squashdelta and have to use different command (e.g. squashmount) afterwards. No, that is not correct [...] 2) /etc/portage/repo.postsync.d I know about this hook, but this is not what I meant. What I meant is the possibility to *replace* the automatic mounting of portage by a different command (for instance, a possibility to *avoid* that portage mounts/umounts automatically but expects this to happens in this hook). I give reasons for this below. (This discussion belongs actually to portage-devel mailing list or to some bug, but now I feel the necessity to clarify the misunderstanding.) It is not only inefficient and hackish (with possible problems in case of unexpected situations like a SIGINT or other signal at a bad time) if two programs/scripts fight about mounts and undo each others' mounts. It also causes severe difficulties in connection with overlayfs/aufs/...: With these filesystems, you must create two (in case of overlayfs even three) auxiliary directories, and in this situation, it might be natural to choose these as temporary direcories (e.g. generated in /tmp with unique names); to understand the following explanation note also that two of these directories (the squash filesystem and the overlay filesystem) should normally always be mounted/umounted together. Now if portage umounts only the overlay directory, the information about the temporary directory names is lost (leaving possibly quite a bit data in /tmp undeleted forever), and the second necessary umount does not happen and is hard to do later on: It prevents the space of the old squash file from actually being freed (and this mount is hard to find later on: It is a mount of a deleted file on an unknown temporary directory. Of course, one could try to find this mount by some heuristic, but this is extremely hackish, and the heuristic might find some other squash file which the user has mounted similarly for some other reason.) In case of the mentioned squashmount tool, the situation is better, because squashmount is rather complex and e.g. stores/manages the names of temporary directories independently. However, users might also want to use less sophisticated tools than squashmount (and also squashmount has no easy solution for random remounts of the mount points it manages, because it is almost impossible to write a generic such solution.) In any case, it is rather hackisch to write a lot of additional code to undo an actually undesired umounting+mounting: The clean solution appears to be to not do the undesired (in this situation) umounting+mounting in the first place but to execute *only* the actually desired (u)mount command(s) instead.
Re: [gentoo-dev] Re: News item review: SquashDelta syncing support
On Mon, 18 May 2015 05:48:59 + (UTC) Martin Vaeth mar...@mvath.de wrote: Rich Freeman ri...@gentoo.org wrote: Downsides include: 2. Impossible to tweak ebuilds without setting up an overlay. This might be annoying for devs/etc. It is still possible to setup a read-writable portage tree (using overlayfs/aufs/unionfs-fuse/... e.g. using the squashmount tool from the mv overlay). However, currently this does not play nicely with squashdelta: You have to undo the mounting of squashdelta and have to use different command (e.g. squashmount) afterwards. Although this can probably be done e.g. in eix-sync with hooks, I hope that in the near future there will be a possibility to combine these methods more conveniently. Currently, I made only some remarks in comment #3 of bug 549716, because it seems that the sync module mechanism is currently lacking the infrastructure for adding custom data (like hooks) to a module. No, that is not correct, the new sync system also introduced a new native portage postsync hook system. 1) /etc/portage/postsync.d/... runs each script once at the completion of all repos that were synced. (no arguments passed in) 2) /etc/portage/repo.postsync.d runs each script at the end of each repo that is synced. Each script can determine if it needs to run or simply exit. Each script is called with 3 arguments the repo name, the url link it was synced to and the path to the repo. Using that information you could easily add a postsync hook there looking for the gentoo repo argument. And if not exit. If it is the gentoo repo, call your squashmount script to remount it your way. See the example script in that directory. -- Brian Dolbec dolsen
[gentoo-dev] Re: News item review: SquashDelta syncing support
Michael Orlitzky posted on Sat, 16 May 2015 20:45:08 -0400 as excerpted: On 05/16/2015 06:00 PM, Michał Górny wrote: Do we need a news item for this at all? Everything is backward compatible and most people don't need to do anything at all in response to the news. No, we don't. But news items are good way to tell people that something is happening. Look at Funtoo. Their users are happy because developers announce stuff rather than expecting them to watch for random things happening. Ok, just keep in mind that you force thousands of people to type `eselect news read new` on all of their machines when you post a feature announcement. That's a good point, and a rather persuasive argument to include the the benefits/down-sides are sections already suggested elsewhere. =:^) IOW, without a benefits/negatives section, you are absolutely correct, there's no obvious reason to post this as a news item as it simply forces a bunch of people to read news and wonder why they should care. But with that benefits/negatives section added, it should become a useful news item, that even people who don't choose to switch to squashdelta should appreciate, as it keeps them informed of changes and allows them to make informed decisions based on them. =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: News item review: SquashDelta syncing support
Michał Górny posted on Sun, 17 May 2015 05:47:15 +0200 as excerpted: Dnia 2015-05-16, o godz. 20:38:36 Michael Orlitzky m...@gentoo.org napisał(a): On 05/16/2015 06:01 PM, Michał Górny wrote: We have gentoo-announce@g.o and gentoo-user@g.o too! That's gentoo-dev-announce. 'dev' is the key part. And gentoo-user@ is doubtedly used by sysadmins. This one: https://archives.gentoo.org/gentoo-announce/ First time I hear about it. Looks to be used primarily for GLSAs. I wonder if anyone actually uses it. Answering the does anyone actually use it bit... I'm subscribed (via gmane) and scan new message subjects, at least, reading messages when they (might) pertain. Tho the GLSAs are of questionable usefulness here, since I'm on ~arch and update regularly enough that announced affected versions are usually ancient history on my boxen. I think I've actually seen one or two that applied to me... in over a decade on gentoo. But I still subscribe and at least scan titles, as for me it's part of being a good admin, just in case, both for the GLSAs, and in case there's anything else of importance posted. Of course if the announce list was actually used for announcements other than GLSAs, it'd definitely enhance its general usefulness. So please do start announcing stuff there -- IMO, anything fit for the front page is fit for the general announce list as well! =:^) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: News item review: SquashDelta syncing support
Rich Freeman ri...@gentoo.org wrote: Downsides include: 2. Impossible to tweak ebuilds without setting up an overlay. This might be annoying for devs/etc. It is still possible to setup a read-writable portage tree (using overlayfs/aufs/unionfs-fuse/... e.g. using the squashmount tool from the mv overlay). However, currently this does not play nicely with squashdelta: You have to undo the mounting of squashdelta and have to use different command (e.g. squashmount) afterwards. Although this can probably be done e.g. in eix-sync with hooks, I hope that in the near future there will be a possibility to combine these methods more conveniently. Currently, I made only some remarks in comment #3 of bug 549716, because it seems that the sync module mechanism is currently lacking the infrastructure for adding custom data (like hooks) to a module.
