Re: pkg_* new functionality: arch, version expansion
On 2015/04/15 23:33, Marc Espie wrote: On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: I've seen at least -beta versions short before release locks. Not sure if there are -alpha too? Those should be treated same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ? As far as I am concerned, -beta should act exactly the same as no tag or -stable, i.e. use the release number. Otherwise it is hard to vetify that a release is going to do the right thing.
Re: pkg_* new functionality: arch, version expansion
On 2015/04/16 12:03, Sebastian Reitenbach wrote: Am 4/15/2015 um 11:33 PM schrieb Marc Espie: On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: I've seen at least -beta versions short before release locks. Not sure if there are -alpha too? Those should be treated same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ? Well, when running pkg_add on a host that has version like X.X-beta, pkg_add will expand %v to /X.X/ in the path. Usually at those time frames where there are -beta versions, such directories aren't on the mirrors (yet), as far as I can see, pkg_add will fail then. Just wondering, if is this intended? I also might be wrong ;) There is also the period when the release version is 5.7 but before packages/firmware are available on mirrors in the 5.7 directory (and actually this usually lasts for longer than the beta phase). I don't have an answer for this, but it seems out-of-scope of what is being done here, as people who know they will always be using snapshots can just insert the word snapshots in the URL themselves rather than using this variable.
Re: pkg_* new functionality: arch, version expansion
Am 4/16/2015 um 12:03 PM schrieb Sebastian Reitenbach: Am 4/15/2015 um 11:33 PM schrieb Marc Espie: On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: I've seen at least -beta versions short before release locks. Not sure if there are -alpha too? Those should be treated same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ? Well, when running pkg_add on a host that has version like X.X-beta, pkg_add will expand %v to /X.X/ in the path. Usually at those time frames I meant %c here that gets expanded in that case. where there are -beta versions, such directories aren't on the mirrors (yet), as far as I can see, pkg_add will fail then. Just wondering, if is this intended? I also might be wrong ;) Sebastian
Re: pkg_* new functionality: arch, version expansion
Am 4/15/2015 um 11:33 PM schrieb Marc Espie: On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: I've seen at least -beta versions short before release locks. Not sure if there are -alpha too? Those should be treated same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ? Well, when running pkg_add on a host that has version like X.X-beta, pkg_add will expand %v to /X.X/ in the path. Usually at those time frames where there are -beta versions, such directories aren't on the mirrors (yet), as far as I can see, pkg_add will fail then. Just wondering, if is this intended? I also might be wrong ;) Sebastian
Re: pkg_* new functionality: arch, version expansion
On Thu, Apr 16, 2015 at 11:19:39AM BST, Stuart Henderson wrote:
On 2015/04/16 12:03, Sebastian Reitenbach wrote:
Am 4/15/2015 um 11:33 PM schrieb Marc Espie:
On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach
wrote:
I've seen at least -beta versions short before release locks. Not
sure if there are -alpha too? Those should be treated same way as
snapshots, I think.
This is the exact same logic that's in fw_update, actually... so
if one is wrong, the other one would be too ?
Well, when running pkg_add on a host that has version like X.X-beta,
pkg_add will expand %v to /X.X/ in the path. Usually at those time
frames where there are -beta versions, such directories aren't on
the mirrors (yet), as far as I can see, pkg_add will fail then.
Just wondering, if is this intended? I also might be wrong ;)
There is also the period when the release version is 5.7 but before
packages/firmware are available on mirrors in the 5.7 directory (and
actually this usually lasts for longer than the beta phase).
I don't have an answer for this, but it seems out-of-scope of what is
being done here, as people who know they will always be using
snapshots can just insert the word snapshots in the URL themselves
rather than using this variable.
That's what I've been doing in my {install,upgrade}.conf after finding
it out the hard way[0].
[0] https://marc.info/?l=openbsd-techm=142554965809503w=2
Cheers,
Raf
pkg_* new functionality: arch, version expansion
was requested by sthen@
works with pkg.conf and PKG_PATH, similar sequences as for dpb:
%a - architecture
%c - either snapshots or version number
%v - always version number.
please test/comment
just tried it after rewriting:
installpath = http://ftp.fr.openbsd.org/pub/OpenBSD/%c/packages/%a/
in pkg.conf
Index: OpenBSD/PackingElement.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackingElement.pm,v
retrieving revision 1.239
diff -u -p -r1.239 PackingElement.pm
--- OpenBSD/PackingElement.pm 25 Feb 2015 16:37:15 - 1.239
+++ OpenBSD/PackingElement.pm 15 Apr 2015 15:53:09 -
@@ -1750,6 +1750,15 @@ sub stringize($)
my ($machine_arch, $arch);
+sub arch
+{
+ if (!defined $arch) {
+ my $cmd = OpenBSD::Paths-uname. -m;
+ chomp($arch = `$cmd`);
+ }
+ return $arch;
+}
+
sub check
{
my ($self, $forced_arch) = @_;
@@ -1768,11 +1777,7 @@ sub check
chomp($machine_arch = `$cmd`);
}
return 1 if $ok eq $machine_arch;
- if (!defined $arch) {
- my $cmd = OpenBSD::Paths-uname. -m;
- chomp($arch = `$cmd`);
- }
- return 1 if $ok eq $arch;
+ return 1 if $ok eq arch();
}
return;
}
Index: OpenBSD/PackageRepository/Installed.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository/Installed.pm,v
retrieving revision 1.29
diff -u -p -r1.29 Installed.pm
--- OpenBSD/PackageRepository/Installed.pm 15 Jun 2014 23:49:51 -
1.29
+++ OpenBSD/PackageRepository/Installed.pm 15 Apr 2015 15:53:09 -
@@ -26,6 +26,40 @@ use warnings;
package OpenBSD::PackageRepositoryBase;
+my ($version, $current);
+
+sub expand_locations
+{
+ my ($class, $string, $state) = @_;
+ if ($string eq '%a') {
+ require OpenBSD::PackingElement;
+ return OpenBSD::PackingElement::Arch::arch();
+ } else {
+ if (!defined $version) {
+ require OpenBSD::Paths;
+ open my $cmd, '-|',
+ OpenBSD::Paths-sysctl, '-n', 'kern.version';
+ my $line = $cmd;
+ close($cmd);
+ if ($line =~ m/^OpenBSD (\d\.\d)(\S*)\s/) {
+ $version = $1;
+ if ($2 eq '-current') {
+ $current = 'snapshots';
+ } else {
+ $current = $version;
+ }
+ } else {
+ $state-fatal(Can't figure out version);
+ }
+ }
+ if ($string eq '%c') {
+ return $current;
+ } else {
+ return $version;
+ }
+ }
+}
+
sub parse_url
{
my ($class, $r, $state) = @_;
@@ -40,6 +74,7 @@ sub parse_url
$$r = '';
}
+ $path =~ s/\%[vac]/$class-expand_locations($, $state)/ge;
$path .= '/' unless $path =~ m/\/$/;
bless { path = $path, state = $state }, $class;
}
Re: pkg_* new functionality: arch, version expansion
On 04/15/15 17:56, Marc Espie wrote:
was requested by sthen@
works with pkg.conf and PKG_PATH, similar sequences as for dpb:
%a - architecture
%c - either snapshots or version number
%v - always version number.
please test/comment
just tried it after rewriting:
installpath = http://ftp.fr.openbsd.org/pub/OpenBSD/%c/packages/%a/
in pkg.conf
Index: OpenBSD/PackingElement.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackingElement.pm,v
retrieving revision 1.239
diff -u -p -r1.239 PackingElement.pm
--- OpenBSD/PackingElement.pm 25 Feb 2015 16:37:15 - 1.239
+++ OpenBSD/PackingElement.pm 15 Apr 2015 15:53:09 -
@@ -1750,6 +1750,15 @@ sub stringize($)
my ($machine_arch, $arch);
+sub arch
+{
+ if (!defined $arch) {
+ my $cmd = OpenBSD::Paths-uname. -m;
+ chomp($arch = `$cmd`);
+ }
+ return $arch;
+}
+
sub check
{
my ($self, $forced_arch) = @_;
@@ -1768,11 +1777,7 @@ sub check
chomp($machine_arch = `$cmd`);
}
return 1 if $ok eq $machine_arch;
- if (!defined $arch) {
- my $cmd = OpenBSD::Paths-uname. -m;
- chomp($arch = `$cmd`);
- }
- return 1 if $ok eq $arch;
+ return 1 if $ok eq arch();
}
return;
}
Index: OpenBSD/PackageRepository/Installed.pm
===
RCS file: /cvs/src/usr.sbin/pkg_add/OpenBSD/PackageRepository/Installed.pm,v
retrieving revision 1.29
diff -u -p -r1.29 Installed.pm
--- OpenBSD/PackageRepository/Installed.pm 15 Jun 2014 23:49:51 -
1.29
+++ OpenBSD/PackageRepository/Installed.pm 15 Apr 2015 15:53:09 -
@@ -26,6 +26,40 @@ use warnings;
package OpenBSD::PackageRepositoryBase;
+my ($version, $current);
+
+sub expand_locations
+{
+ my ($class, $string, $state) = @_;
+ if ($string eq '%a') {
+ require OpenBSD::PackingElement;
+ return OpenBSD::PackingElement::Arch::arch();
+ } else {
+ if (!defined $version) {
+ require OpenBSD::Paths;
+ open my $cmd, '-|',
+ OpenBSD::Paths-sysctl, '-n', 'kern.version';
+ my $line = $cmd;
+ close($cmd);
+ if ($line =~ m/^OpenBSD (\d\.\d)(\S*)\s/) {
+ $version = $1;
+ if ($2 eq '-current') {
+ $current = 'snapshots';
I've seen at least -beta versions short before release locks. Not
sure if there are -alpha too? Those should be treated
same way as snapshots, I think.
+ } else {
+ $current = $version;
+ }
+ } else {
+ $state-fatal(Can't figure out version);
+ }
+ }
+ if ($string eq '%c') {
+ return $current;
+ } else {
+ return $version;
+ }
+ }
+}
+
sub parse_url
{
my ($class, $r, $state) = @_;
@@ -40,6 +74,7 @@ sub parse_url
$$r = '';
}
+ $path =~ s/\%[vac]/$class-expand_locations($, $state)/ge;
$path .= '/' unless $path =~ m/\/$/;
bless { path = $path, state = $state }, $class;
}
Re: pkg_* new functionality: arch, version expansion
On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: I've seen at least -beta versions short before release locks. Not sure if there are -alpha too? Those should be treated same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ?
