On 09/22/2016 03:53 AM, Gordian Edenhofer wrote:
> I wouldn't assume that the user has done anything wrong, rather
> something with the system is wrong if one feels the need to 'backup'
> packages.
Awesome, we must be in agreement, because I don't think people should
feel the need to backup
On Wed, 2016-09-21 at 23:28 -0400, Eli Schwartz wrote:
> On 09/21/2016 05:56 AM, Gordian Edenhofer wrote:
> >
> > You bar for insanity is whether the debian folks do it? Please
> > explain
> > yourself why do you think this is the wrong approach for the
> > problem.
> > My reasoning would be that
On 09/21/2016 05:56 AM, Gordian Edenhofer wrote:
> You bar for insanity is whether the debian folks do it? Please explain
> yourself why do you think this is the wrong approach for the problem.
> My reasoning would be that packaging a dummy package would result in
> the same 'renamed' package on
On Tue, 2016-09-20 at 21:41 -0400, Eli Schwartz wrote:
> On 09/19/2016 11:49 AM, Gordian Edenhofer wrote:
> >
> > What about adding a new option to pacman's '-D, --database'
> > operator
> > which would enable users to rename packages and add a corresponding
> > provide field. This would empower
On 09/19/2016 11:49 AM, Gordian Edenhofer wrote:
> What about adding a new option to pacman's '-D, --database' operator
> which would enable users to rename packages and add a corresponding
> provide field. This would empower everyone to decide on their own which
> packages they want in different
On Mon, 2016-09-12 at 21:33 -0400, Eli Schwartz wrote:
> On 09/12/2016 06:51 PM, Allan McRae wrote:
> >
> > This discussion has nothing to do with Arch. It is about whether
> > this
> > feature needs implemented in pacman.
>
> Which of course it doesn't. All we need is for the kernel maintainer
On 09/12/2016 06:51 PM, Allan McRae wrote:
> This discussion has nothing to do with Arch. It is about whether this
> feature needs implemented in pacman.
Which of course it doesn't. All we need is for the kernel maintainer to
start packaging a dummy linux package that depends on linux-$pkgver
On 12/09/16 22:59, Johannes Löthberg wrote:
> On 12/09, Sergey Petrenko via pacman-dev wrote:
>> Well, of course! I can also build kernel outside package management,
>> or write a hook to backup kernels, but I'd like to see solution that
>> would not require such dire and time consuming measures,
On 12/09, Sergey Petrenko via pacman-dev wrote:
Well, of course! I can also build kernel outside package management, or write a
hook to backup kernels, but I'd like to see solution that would not require
such dire and time consuming measures, and, ideally, would not require actions
from me at
Well, of course! I can also build kernel outside package management, or write a
hook to backup kernels, but I'd like to see solution that would not require
such dire and time consuming measures, and, ideally, would not require actions
from me at all.
>Понедельник, 12 сентября 2016, 10:22
On 09/12/16 at 09:47am, Sergey Petrenko via pacman-dev wrote:
> Should I spam kernel package maintainers then, or maybe someone will resolve
> bug as wontfix?
Not sure why they need to be spammed, you can easily build linux47 as a
package and install it separate from the normal linux package.
Should I spam kernel package maintainers then, or maybe someone will resolve
bug as wontfix?
>Суббота, 10 сентября 2016, 0:58 +03:00 от Allan McRae :
>
>On 10/09/16 08:41, Sergey Petrenko via pacman-dev wrote:
>> Here is my attempt to solve seven years old infamous problem:
On 10/09/16 08:41, Sergey Petrenko via pacman-dev wrote:
> Here is my attempt to solve seven years old infamous problem:
> https://bugs.archlinux.org/task/16702
>
> Patch won't solve problem out of the box, a small changes in kernel PKGBUILD
> will be required, but only concerning install part.
>
Here is my attempt to solve seven years old infamous problem:
https://bugs.archlinux.org/task/16702
Patch won't solve problem out of the box, a small changes in kernel PKGBUILD
will be required, but only concerning install part.
Idea behind patch is pretty simple:
1) Configure list of packages
Hi,
If two repos (obviously not both official) provide the same binary package,
pacman will install the package from the repo that is listed first in
pacman.conf, if specified on the command line, e.g. pacman -S foo.
If another package depends on foo, the same thing happens, but if it instead
On Thu, Nov 11, 2010 at 8:46 PM, Xyne x...@archlinux.ca wrote:
Hi,
If two repos (obviously not both official) provide the same binary package,
pacman will install the package from the repo that is listed first in
pacman.conf, if specified on the command line, e.g. pacman -S foo.
If another
Xavier Chantry wrote:
On Thu, Nov 11, 2010 at 8:46 PM, Xyne x...@archlinux.ca wrote:
Hi,
If two repos (obviously not both official) provide the same binary package,
pacman will install the package from the repo that is listed first in
pacman.conf, if specified on the command line, e.g.
17 matches
Mail list logo