[pacman-dev] [PATCH] Remove SyncFirst option
seblu at seblu.net
Wed Feb 15 09:14:21 EST 2012
On Wed, Feb 15, 2012 at 2:56 PM, Dan McGee <dpmcgee at gmail.com> wrote:
> On Tue, Feb 14, 2012 at 4:08 PM, Dave Reisner <d at falconindy.com> wrote:
>> On Tue, Feb 14, 2012 at 02:30:06PM -0600, Dan McGee wrote:
>>> This has outlived its usefulness and causes more problems than it
>>> Signed-off-by: Dan McGee <dan at archlinux.org>
>>> This is an RFC first of all, so please feel free to comment.
>>> 1. Removes complexity and a fair amount of code.
>>> 2. Removes the hack necesary for download-only and print operations.
>>> 3. Closes at least two bug reports.
>>> 4. Pacman is now much more resiliant to updates to itself since vercmp is
>>> statically linked, etc. so updating it alone isn't always necessary.
>>> 1. If a major underlying change occurs (such as a new compression format),
>>> users would need to update pacman explicitly first.
>>> 2. ???
>> Just to be a jerk... Suppose the following:
>> - The fabled keyring package exists. Life is awesome.
>> - I go insane and have to be forcefully removed from the dev team, and
>> my packaging key needs to be blacklisted. Alternatively, I'm off on
>> vacation and my desktop+gpg key is compromised. Same end effect.
>> - It's assumed that a number of the packages that I maintain are now
>> highly suspect and should NOT be installed.
>> In this case, SyncFirst seems like the only way to make sure that people
>> are safe from the rootkits that are infecting my packages.
> Another alternative that came to me this morning, that even means we
> don't really need to rename the option, only re-document it. What if
> SyncFirst simply moved packages to the top of the targets list by
> default? Since right now we simply keep targets in alphabetical order
> (outside of necessary dependency reordering), what if being in
> SyncFirst gave you a free ticket to the head of the line?
> If one kept pacman in SyncFirst, it would get pulled up, and then via
> dep reordering, would be behind only the packages it depends on, which
> is kind of what we have wanted all along, except now we continue to
> install everything else as well. If someone was silly enough to
> interrupt the sync operation, there is a slightly smaller chance they
> leave themselves in a bad situation.
What would be the interest of doing this?
SyncFirst is useful to force some update to be completed before
upgrade the remaining packages and pacman be run again.
Currently, pacman is in syncfirst, as we want pacman be up-to-date
before installing new packages. With this new behaviour, add pacman in
syncfirst, will change something?
All packages will be upgraded with old pacman and next upgrade will be
done with new one. What is the purpose of ordering in the package
More information about the pacman-dev