Re: [pacman-dev] Versioned packages

[Eli Schwartz]

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 package*s* either.

> Since one is intending to backup a package one should be highly aware
> of the purpose of the package.

What does that have to do with anything???

> The provide field makes sure that it is still treated the same. But to
> allow backups for all packages, the user has to live with them not
> being signed-off.

Okay. What about reinstalling this mysterious ghost-like package?
And when, precisely, did you decide that "backups for all packages" was
a desirable feature, rather than a highly kludgy workaround for the edge
case of the linux kernel?

> I dislike dummy packages and therefore would keep the current way of
> creating e.g. the linux package.
> If using dummy packages the main question becomes where to draw the
> line. You are currently referring to linux as "for that specific
> package" but what if users need different versions for another
> package... The system of everyone else would become more and more
> cluttered with dummy packages.

To add to my previous objections: Arch Linux doesn't believe in running
old software, and the linux is a unique exception whereby we don't want
to delete a currently-running kernel, the solution to which is not
"let's modify pacman".


Maybe the source of this confusion is, you should read the bugtracker to
see why this thread was initially proposed, and then decide if backing
up package*s* is a good solution.
Rather than presupposing it is a wanted feature. (feature creep)
https://bugs.archlinux.org/task/16702

-- 
Eli Schwartz

Re: [pacman-dev] Versioned packages

[Gordian Edenhofer]

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 packaging a dummy package would result
> > in
> > the same 'renamed' package on the system but would require the
> > package
> > maintainer to take action.
> 
> Well, I can usually count on them to be over-engineered.
> 
> But in all seriousness, then. :)
> Building in to the package manager, a capacity for retroactively
> modifying the definition of a specific package, seems to me to be a
> clear case of over-engineering. And just a bad idea in principle.
> 
> If you want to do that, it is because you are already doing
> *something*
> wrong.

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.

> Because, you should not have to change your mind about what these
> particular files actually are, and start calling them something else
> on

Since one is intending to backup a package one should be highly aware
of the purpose of the package.

> a whim. Particularly as it disappears from the repositories, stops
> being
> trusted as signed by a central authority (the TUs), cannot be
> reinstalled...

The provide field makes sure that it is still treated the same. But to
allow backups for all packages, the user has to live with them not
being signed-off.

> > Btw. my Arch system is rock solid and I am not especially
> > interested in
> > dummy packages on my system but for those who need it it can be a
> > huge
> > difference. Therefore it makes sense to give those specific user
> > base
> > the ability to do so on their own. It wouldn't even be a dangerous
> > operation since by adding a provide field one should be unable to
> > brick
> > the system.
> > However I admit that it would require some additions to pacman
> > which is
> > obviously an argument against this but the way packages are treated
> > would stay the same.
> > Currently I don't see a reason why one should change the way of
> > packaging just to circumvent the underlying problem.
> 
> I am a bit confused as to what this all means...
> 
> Do you prefer dummy packages which pull in versioned kernels and
> depend
> on changing the packaging (for that specific package)?
> Or do you prefer additions to pacman while "treating the packages the
> same"?

I dislike dummy packages and therefore would keep the current way of
creating e.g. the linux package.
If using dummy packages the main question becomes where to draw the
line. You are currently referring to linux as "for that specific
package" but what if users need different versions for another
package... The system of everyone else would become more and more
cluttered with dummy packages.

> I think we may have a drastically different idea of what constitutes
> "circumventing the underlying problem".
> To be specific, we both seem to think the other is the one
> circumventing
> the underlying problem.

That's true :D

signature.asc
Description: This is a digitally signed message part

Re: [pacman-dev] Versioned packages

[Eli Schwartz]

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 the system but would require the package
> maintainer to take action.

Well, I can usually count on them to be over-engineered.

But in all seriousness, then. :)
Building in to the package manager, a capacity for retroactively
modifying the definition of a specific package, seems to me to be a
clear case of over-engineering. And just a bad idea in principle.

If you want to do that, it is because you are already doing *something*
wrong.
Because, you should not have to change your mind about what these
particular files actually are, and start calling them something else on
a whim. Particularly as it disappears from the repositories, stops being
trusted as signed by a central authority (the TUs), cannot be reinstalled...

> Btw. my Arch system is rock solid and I am not especially interested in
> dummy packages on my system but for those who need it it can be a huge
> difference. Therefore it makes sense to give those specific user base
> the ability to do so on their own. It wouldn't even be a dangerous
> operation since by adding a provide field one should be unable to brick
> the system.
> However I admit that it would require some additions to pacman which is
> obviously an argument against this but the way packages are treated
> would stay the same.
> Currently I don't see a reason why one should change the way of
> packaging just to circumvent the underlying problem.

I am a bit confused as to what this all means...

Do you prefer dummy packages which pull in versioned kernels and depend
on changing the packaging (for that specific package)?
Or do you prefer additions to pacman while "treating the packages the same"?

...

I think we may have a drastically different idea of what constitutes
"circumventing the underlying problem".
To be specific, we both seem to think the other is the one circumventing
the underlying problem.

-- 
Eli Schwartz

Re: [pacman-dev] Versioned packages

[Gordian Edenhofer]

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 everyone to decide on their own
> > which
> > packages they want in different versions and which they don't want.
> > Pacman would handle file conflicts as usual without introducing a
> > new
> > kind of packages. Plus it would avoid discussions about which
> > package
> > should be a dummy package and which shouldn't be.
> 
> Was that meant to be some sort of a joke? Because even Debian is not
> that insane, AFAIK.

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 the system but would require the package
maintainer to take action.
Btw. my Arch system is rock solid and I am not especially interested in
dummy packages on my system but for those who need it it can be a huge
difference. Therefore it makes sense to give those specific user base
the ability to do so on their own. It wouldn't even be a dangerous
operation since by adding a provide field one should be unable to brick
the system.
However I admit that it would require some additions to pacman which is
obviously an argument against this but the way packages are treated
would stay the same.
Currently I don't see a reason why one should change the way of
packaging just to circumvent the underlying problem.

signature.asc
Description: This is a digitally signed message part

Re: [pacman-dev] Versioned packages

[Eli Schwartz]

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 versions and which they don't want.
> Pacman would handle file conflicts as usual without introducing a new
> kind of packages. Plus it would avoid discussions about which package
> should be a dummy package and which shouldn't be.

Was that meant to be some sort of a joke? Because even Debian is not
that insane, AFAIK.

-- 
Eli Schwartz

Re: [pacman-dev] Versioned packages

[Gordian Edenhofer]

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
> to
> start packaging a dummy linux package that depends on linux-$pkgver
> packages.
> 
> As originally recommended by the bugtracker item which spawned this
> odd
> thread.
> 
> ...
> 
> I am not quite sure what is currently blocking such a resolution, but
> that is already supposedly being discussed on the bugtracker.
> 
> Meanwhile let us listen to people proposing convoluted workarounds
> that
> evade the issue entirely and are far less likely to actually be
> accepted...

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 versions and which they don't want.
Pacman would handle file conflicts as usual without introducing a new
kind of packages. Plus it would avoid discussions about which package
should be a dummy package and which shouldn't be.

Best Regards,
Gordian Edenhofer

signature.asc
Description: This is a digitally signed message part

Re: [pacman-dev] Versioned packages

[Eli Schwartz]

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
packages.

As originally recommended by the bugtracker item which spawned this odd
thread.

...

I am not quite sure what is currently blocking such a resolution, but
that is already supposedly being discussed on the bugtracker.

Meanwhile let us listen to people proposing convoluted workarounds that
evade the issue entirely and are far less likely to actually be accepted...

-- 
Eli Schwartz

Re: [pacman-dev] Versioned packages

[Allan McRae]

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, and, ideally,
>> would not require actions from me at all.
>>
> 
> Then maybe Arch is not for you.
> 

This discussion has nothing to do with Arch.  It is about whether this
feature needs implemented in pacman.

Allan

Re: [pacman-dev] Versioned packages

[Johannes Löthberg]

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 all.



Then maybe Arch is not for you.

--
Sincerely,
 Johannes Löthberg
 PGP Key ID: 0x50FB9B273A9D0BB5
 https://theos.kyriasis.com/~kyrias/


signature.asc
Description: PGP signature

Re: [pacman-dev] Versioned packages

[Sergey Petrenko via pacman-dev]

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 +03:00 от Jelle van der Waa 
>:
>
>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. But I
>guess you want to automatically retain your current installed linux pkg
>when you upgrade to a newer version?
>
>> 
>> 
>> >Суббота, 10 сентября 2016, 0:58 +03:00 от Allan McRae < al...@archlinux.org 
>> >>:
>> >
>> >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.
>> >> 
>> >> Idea behind patch is pretty simple:
>> >> 1) Configure list of packages and number of old versions pacman should 
>> >> try 
>> >> to preserve.
>> >> 2) When upgading to new version, keep old in place, if it has no file 
>> >> conflicts with new one, and mark it as `archived`, remove oldest 
>> >> `archived` 
>> >> version instead.
>> >> 
>> >> Most of time pacman treats `archived` packages as if they aren't 
>> >> installed.
>> >> For now it won't check package conflicts and dependencies, only file 
>> >> conflicts 
>> >> with newer versions. It's only an outline of full solution, proof of 
>> >> concept 
>> >> to illustrate the idea.
>> >> 
>> >> I'd like to hear opinion of community whether this problem should be 
>> >> solved 
>> >> at all, or is it more like a feature of ArchLinux, and if it should, 
>> >> whether
>> >> such approach suits ArchLinux's philosophy.
>> >> 
>> >
>> >How is this better than having a package file sitting in the cache?
>> >
>> >The "kernel problem" in Arch is not because it is not possible to have
>> >multiple kernel packages available.  Other distributions provide endless
>> >amounts of kernels (e.g. Manjaro).
>> >
>> >I don't see anything that needs done on the package manager end for this.
>> >
>> >Allan
>> 
>> 
>> -- 
>> With wish of constant improvement
>> and unstoppable creativity.
>> Sergey Petrenko
>
>-- 
>Jelle van der Waa


-- 
With wish of constant improvement
and unstoppable creativity.
Sergey Petrenko

Re: [pacman-dev] Versioned packages

[Jelle van der Waa]

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. But I
guess you want to automatically retain your current installed linux pkg
when you upgrade to a newer version?

> 
> 
> >Суббота, 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:
> >>  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 and number of old versions pacman should try 
> >> to preserve.
> >> 2) When upgading to new version, keep old in place, if it has no file 
> >> conflicts with new one, and mark it as `archived`, remove oldest 
> >> `archived` 
> >> version instead.
> >> 
> >> Most of time pacman treats `archived` packages as if they aren't installed.
> >> For now it won't check package conflicts and dependencies, only file 
> >> conflicts 
> >> with newer versions. It's only an outline of full solution, proof of 
> >> concept 
> >> to illustrate the idea.
> >> 
> >> I'd like to hear opinion of community whether this problem should be 
> >> solved 
> >> at all, or is it more like a feature of ArchLinux, and if it should, 
> >> whether
> >> such approach suits ArchLinux's philosophy.
> >> 
> >
> >How is this better than having a package file sitting in the cache?
> >
> >The "kernel problem" in Arch is not because it is not possible to have
> >multiple kernel packages available.  Other distributions provide endless
> >amounts of kernels (e.g. Manjaro).
> >
> >I don't see anything that needs done on the package manager end for this.
> >
> >Allan
> 
> 
> -- 
> With wish of constant improvement
> and unstoppable creativity.
> Sergey Petrenko

-- 
Jelle van der Waa


signature.asc
Description: PGP signature

Re: [pacman-dev] Versioned packages

[Sergey Petrenko via pacman-dev]

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:
>>  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 and number of old versions pacman should try 
>> to preserve.
>> 2) When upgading to new version, keep old in place, if it has no file 
>> conflicts with new one, and mark it as `archived`, remove oldest `archived` 
>> version instead.
>> 
>> Most of time pacman treats `archived` packages as if they aren't installed.
>> For now it won't check package conflicts and dependencies, only file 
>> conflicts 
>> with newer versions. It's only an outline of full solution, proof of concept 
>> to illustrate the idea.
>> 
>> I'd like to hear opinion of community whether this problem should be solved 
>> at all, or is it more like a feature of ArchLinux, and if it should, whether
>> such approach suits ArchLinux's philosophy.
>> 
>
>How is this better than having a package file sitting in the cache?
>
>The "kernel problem" in Arch is not because it is not possible to have
>multiple kernel packages available.  Other distributions provide endless
>amounts of kernels (e.g. Manjaro).
>
>I don't see anything that needs done on the package manager end for this.
>
>Allan


-- 
With wish of constant improvement
and unstoppable creativity.
Sergey Petrenko

Re: [pacman-dev] Versioned packages

[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:
> 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 and number of old versions pacman should try 
> to preserve.
> 2) When upgading to new version, keep old in place, if it has no file 
> conflicts with new one, and mark it as `archived`, remove oldest `archived` 
> version instead.
> 
> Most of time pacman treats `archived` packages as if they aren't installed.
> For now it won't check package conflicts and dependencies, only file 
> conflicts 
> with newer versions. It's only an outline of full solution, proof of concept 
> to illustrate the idea.
> 
> I'd like to hear opinion of community whether this problem should be solved 
> at all, or is it more like a feature of ArchLinux, and if it should, whether
> such approach suits ArchLinux's philosophy.
> 

How is this better than having a package file sitting in the cache?

The "kernel problem" in Arch is not because it is not possible to have
multiple kernel packages available.  Other distributions provide endless
amounts of kernels (e.g. Manjaro).

I don't see anything that needs done on the package manager end for this.

Allan

[pacman-dev] Versioned packages

[Sergey Petrenko via pacman-dev]

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 and number of old versions pacman should try 
to preserve.
2) When upgading to new version, keep old in place, if it has no file 
conflicts with new one, and mark it as `archived`, remove oldest `archived` 
version instead.

Most of time pacman treats `archived` packages as if they aren't installed.
For now it won't check package conflicts and dependencies, only file conflicts 
with newer versions. It's only an outline of full solution, proof of concept 
to illustrate the idea.

I'd like to hear opinion of community whether this problem should be solved 
at all, or is it more like a feature of ArchLinux, and if it should, whether
such approach suits ArchLinux's philosophy.

[pacman-dev] Versioned packages on the command line.

[Xyne]

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
depends on foo=1.4 and only the second repo provides it, then pacman will
correctly skip over the first repo and install it from the second.

If so, would you consider making it possible to specify versions directly on
the command line, e.g. pacman -S foo=1.4. I know that it's possible to first
do a search for the package to see which repos contain it, then prepend the
repo, e.g. pacman -S second-repo/foo, but it would be more useful sometimes to
be able to just specify the version using =, =, etc. This would ideally
also work for detecting providers too, e.g. if bar provides foo=1.4 then
pacman -S foo=1.4 would install bar (or bring up the provider selection
dialogue once that's included... I really like that idea btw... considered
doing that in powerpill at some point)



For a possible use of this, see the following post on the arch-haskell mailing
list:
http://www.haskell.org/pipermail/arch-haskell/2010-November/000740.html


Regards,
Xyne

Re: [pacman-dev] Versioned packages on the command line.

[Xavier Chantry]

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 package depends on foo, the same thing happens, but if it instead
 depends on foo=1.4 and only the second repo provides it, then pacman will
 correctly skip over the first repo and install it from the second.

 If so, would you consider making it possible to specify versions directly on
 the command line, e.g. pacman -S foo=1.4. I know that it's possible to first
 do a search for the package to see which repos contain it, then prepend the
 repo, e.g. pacman -S second-repo/foo, but it would be more useful sometimes 
 to
 be able to just specify the version using =, =, etc. This would ideally
 also work for detecting providers too, e.g. if bar provides foo=1.4 then
 pacman -S foo=1.4 would install bar (or bring up the provider selection
 dialogue once that's included... I really like that idea btw... considered
 doing that in powerpill at some point)



 For a possible use of this, see the following post on the arch-haskell mailing
 list:
 http://www.haskell.org/pipermail/arch-haskell/2010-November/000740.html



Did you actually try it ?

Re: [pacman-dev] Versioned packages on the command line.

[Xyne]

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. pacman -S foo.
 
  If another package depends on foo, the same thing happens, but if it 
  instead
  depends on foo=1.4 and only the second repo provides it, then pacman will
  correctly skip over the first repo and install it from the second.
 
  If so, would you consider making it possible to specify versions directly on
  the command line, e.g. pacman -S foo=1.4. I know that it's possible to 
  first
  do a search for the package to see which repos contain it, then prepend the
  repo, e.g. pacman -S second-repo/foo, but it would be more useful 
  sometimes to
  be able to just specify the version using =, =, etc. This would ideally
  also work for detecting providers too, e.g. if bar provides foo=1.4 then
  pacman -S foo=1.4 would install bar (or bring up the provider selection
  dialogue once that's included... I really like that idea btw... considered
  doing that in powerpill at some point)
 
 
 
  For a possible use of this, see the following post on the arch-haskell 
  mailing
  list:
  http://www.haskell.org/pipermail/arch-haskell/2010-November/000740.html
 
 
 
 Did you actually try it ?

Sorry, I had only tried -Si foo=x.y.

Thanks for being pre-emptively awesome. :)