On Mon, Mar 07, 2016 at 11:48:22AM +0000, Iain Lane wrote: > /etc/apt/apt.conf.d/50appstream (how do you even turn this off > per-repository?) (man 5 sources.list describes how to do it) > > But back to topic: In the default install case (and if you really want > > to) you could package the apt.conf-file separately in a -data package > > (which presumably would have no dependencies) and install it as part of > > your bootstrap so it is around at the time apt is first run. Then you > > just have to run the post-processing (if any) at a later point. > > > > Might be that I am too used to all this stuff that I don't see the > > problem with it anymore… > > The problem is that you can't install gnome-software and have it just > work. Just Working on first install is something that Debian packages > try to do if there is a reasonable default configuration. There > absolutely is a reasonable default in this case. It seems to me that it > is going to be so uncommon for people to want to tweak this that putting > the burden on all users is quite harsh. I was hoping you could offer a > solution, but instead you don't even seem to recognise there is anything > to solve. That would be an opportunity to show me what I don't recognise as I was quite openly admitting that I might miss the forest for all the trees, not to attack me quite harshly. I don't see a problem as I would expect a tool using this data to recognize if the data isn't present (or outdated!) – as it surely did already before it delegated the task for getting the files to libapt – and at least tell the user about it. For the stuff built on top of packagekit and consort I would actually be surprised if they wouldn't just trigger an update in the background and tell the user to stand by for a minute, just like a webbrowser would do it with its blocklist… Getting the data right after an apt call finished – or even in the middle of it – seems to have a bunch of problems right from the start: 1. apt should be relatively low-level; an installer would be unhappy if we run an update after each package set the installer installs. 2. a user might still need to configure what needs to be done 3. what should be done in case of a failing apt operation? 4. if we implement it in apt only users of other tools (aptitude, synaptics, …) are out in the blue, so it would be libapt, but that is going to surprise frontends – and needs UI changes to tell the user about the update we run. 5. How do we deal with upgrades done while offline? 6. What happens if the acquisition fails (offline, incompatible proxy, …)? Especially the later points make it close to a requirement that the data-using tool is checking if the data is present/current anyhow, so we can't even argue that we make life easier for the upper stack – we quite likely make it harder for them in fact (1, 4). That is why I don't see the problem apt is in the position to solve. Now, if you would have the decency to explain why you see a problem with arguments instead implicitly calling me a stubborn idiot I would be very pleased. Best regards David Kalnischkies
Attachment:
signature.asc
Description: PGP signature