2:49 a.m.
To put it shortly, I going to switch the default rpm queryformat to
include package architecture (ie what you get now with
rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
so.
This is something that should've been done several releases ago really,
but since it presumably breaks all sorts of scripts people have it's
gotten delayed and delayed... The next major rpm.org release changes the
default anyway, this is just an initial step to see what breaks.
If you know the change would break some of the buildsystem / other
critical Fedora infrastructure, please holler NOW! I can delay the change
a bit to allow critical pieces to be fixed first, but F9 *will* have the
new queryformat so better prepare for it...
Fixing any scripts that absolutely rely on the old default is trivial:
just them use explicit --qf "%{name}-%{version}-%{release}"
- Panu -
4:26 a.m.
On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
To put it shortly, I going to switch the default rpm queryformat to
include package architecture (ie what you get now with
rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
so.
+1000000000000000000000000
Fixing any scripts that absolutely rely on the old default is
trivial:
just them use explicit --qf "%{name}-%{version}-%{release}"
Or better yet, fix your script to use and parse a more explicit
queryformat.
--
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>
PLEASE don't CC me; I'm already subscribed
4:55 a.m.
Panu Matilainen wrote:
To put it shortly, I going to switch the default rpm queryformat to
include package architecture (ie what you get now with
rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or so.
This is something that should've been done several releases ago really,
but since it presumably breaks all sorts of scripts people have it's
gotten delayed and delayed... The next major rpm.org release changes the
default anyway, this is just an initial step to see what breaks.
If you know the change would break some of the buildsystem / other
critical Fedora infrastructure, please holler NOW! I can delay the
change a bit to allow critical pieces to be fixed first, but F9 *will*
have the new queryformat so better prepare for it...
Fixing any scripts that absolutely rely on the old default is trivial:
just them use explicit --qf "%{name}-%{version}-%{release}"
Excellent then I can finally remove my rpm alias adding that as query format
from my .bashrc :)
Regards,
Hans
6:17 p.m.
On Nov 21, 2007 2:55 AM, Hans de Goede <j.w.r.degoede(a)hhs.nl> wrote:
Excellent then I can finally remove my rpm alias adding that as query format
from my .bashrc :)
You don't need a bash alias. You can set the default format in the
.rpmmacros file:
%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
- Ian
7:15 a.m.
On Wed, 2007-11-21 at 11:55 +0100, Hans de Goede wrote:
Panu Matilainen wrote:
>
> To put it shortly, I going to switch the default rpm queryformat to
> include package architecture (ie what you get now with
> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
so.
>
> This is something that should've been done several releases ago really,
> but since it presumably breaks all sorts of scripts people have it's
> gotten delayed and delayed... The next major rpm.org release changes the
> default anyway, this is just an initial step to see what breaks.
>
> If you know the change would break some of the buildsystem / other
> critical Fedora infrastructure, please holler NOW! I can delay the
> change a bit to allow critical pieces to be fixed first, but F9 *will*
> have the new queryformat so better prepare for it...
>
> Fixing any scripts that absolutely rely on the old default is trivial:
> just them use explicit --qf "%{name}-%{version}-%{release}"
>
Excellent then I can finally remove my rpm alias adding that as query format
from my .bashrc :)
Regards,
Hans
No need to.
Just add %_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}
To your .rpmmacros.
- Gilboa
5 p.m.
On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
To put it shortly, I going to switch the default rpm queryformat to
include package architecture (ie what you get now with
rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
so.
Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
1:28 a.m.
Am Donnerstag, den 22.11.2007, 17:00 -0600 schrieb Callum Lerwick:
On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> To put it shortly, I going to switch the default rpm queryformat to
> include package architecture (ie what you get now with
> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
> so.
Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
That would encourage the use of epochs.
2:59 a.m.
On Fri, 2007-11-23 at 08:28 +0100, nodata wrote:
Am Donnerstag, den 22.11.2007, 17:00 -0600 schrieb Callum Lerwick:
> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> > To put it shortly, I going to switch the default rpm queryformat to
> > include package architecture (ie what you get now with
> > rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days
or
> > so.
>
> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
That would encourage the use of epochs.
I don't think so -- "Look, this package has an epoch, I'll add that to
my package too"? Hardly. If I'm interested in the version of a package,
I'm interested in the epoch, too, if there's one. IMO, the only reason
against listing the epoch here is that RPM itself doesn't understand it
when specifying packages:
nils@wombat:~> rpm -q gimp-2:2.4.1-1.fc8.x86_64
package gimp-2:2.4.1-1.fc8.x86_64 is not installed
nils@wombat:~> rpm -q gimp-2.4.1-1.fc8.x86_64
gimp-2.4.1-1.fc8
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
2:16 a.m.
On Fri, 23 Nov 2007, Nils Philippsen wrote:
On Fri, 2007-11-23 at 08:28 +0100, nodata wrote:
> Am Donnerstag, den 22.11.2007, 17:00 -0600 schrieb Callum Lerwick:
>> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>>> To put it shortly, I going to switch the default rpm queryformat to
>>> include package architecture (ie what you get now with
>>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few
days or
>>> so.
>>
>> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
> That would encourage the use of epochs.
Hardly. It would however stop the ages old pretense of epochs being some
mysterious invisible evil people are afraid to talk aloud of. It would
also largely stop the "look I found a bug in rpm: it thinks foo-1.2 is
newer than foo-2.0" reports/questions.
To go that route I think the default file name should also be changed to
include epoch if present. Would probably break another big bunch of
scripts people have, but relying on filename for rpm name and version
information is very broken to begin with anyway (and easily fixed)
The ugly part is that it makes parsing harder as you have to account for
the possibility of epoch being or not being there always, but OTOH you can
always pick your own queryformat if you don't want to deal with it.
I don't think so -- "Look, this package has an epoch,
I'll add that to
my package too"? Hardly. If I'm interested in the version of a package,
I'm interested in the epoch, too, if there's one. IMO, the only reason
against listing the epoch here is that RPM itself doesn't understand it
when specifying packages:
nils@wombat:~> rpm -q gimp-2:2.4.1-1.fc8.x86_64
package gimp-2:2.4.1-1.fc8.x86_64 is not installed
nils@wombat:~> rpm -q gimp-2.4.1-1.fc8.x86_64
gimp-2.4.1-1.fc8
That can be fix.
- Panu -
2:48 a.m.
Panu Matilainen wrote:
The ugly part is that it makes parsing harder as you have to account for
the possibility of epoch being or not being there always, but OTOH you
can always pick your own queryformat if you don't want to deal with it.
Can't you unconditionally have a epoch number listed all the time? 0 if
there is no epoch for that package.
Rahul
3:46 a.m.
On Sat, 24 Nov 2007, Rahul Sundaram wrote:
Panu Matilainen wrote:
>
> The ugly part is that it makes parsing harder as you have to account for
> the possibility of epoch being or not being there always, but OTOH you can
> always pick your own queryformat if you don't want to deal with it.
Can't you unconditionally have a epoch number listed all the time? 0 if there
is no epoch for that package.
Obviously you CAN, but do you REALLY want to?
- Panu -
4:23 a.m.
New subject: repotags and rpm default queryformat (was: Re: Changing the rpm default queryformat to include arch)
On 24.11.2007 10:46, Panu Matilainen wrote:
On Sat, 24 Nov 2007, Rahul Sundaram wrote:
> Panu Matilainen wrote:
>> The ugly part is that it makes parsing harder as you have to account for
>> the possibility of epoch being or not being there always, but OTOH you can
>> always pick your own queryformat if you don't want to deal with it.
> Can't you unconditionally have a epoch number listed all the time? 0 if there
> is no epoch for that package.
Obviously you CAN, but do you REALLY want to?
While at discussing rpm's default queryformat -- should we get the
information where a packages comes from integrated *somewhere* (maybe no
"rpm -q") in the output from rpm or yum as well to finally solve the old
"repotags are useful" vs. "repotags are evil" debate?
CU
knurd
6:08 a.m.
Panu Matilainen wrote:
On Sat, 24 Nov 2007, Rahul Sundaram wrote:
> Panu Matilainen wrote:
>
>>
>> The ugly part is that it makes parsing harder as you have to account
>> for the possibility of epoch being or not being there always, but
>> OTOH you can always pick your own queryformat if you don't want to
>> deal with it.
>
> Can't you unconditionally have a epoch number listed all the time? 0
> if there is no epoch for that package.
Obviously you CAN, but do you REALLY want to?
Personally, yes. I would like to see epoch listed always so that we get
a consistent format for other scripts to parse.
Rahul
7:08 a.m.
On Mon, 2007-11-26 at 17:38 +0530, Rahul Sundaram wrote:
Panu Matilainen wrote:
> On Sat, 24 Nov 2007, Rahul Sundaram wrote:
>
>> Panu Matilainen wrote:
>>
>>>
>>> The ugly part is that it makes parsing harder as you have to account
>>> for the possibility of epoch being or not being there always, but
>>> OTOH you can always pick your own queryformat if you don't want to
>>> deal with it.
>>
>> Can't you unconditionally have a epoch number listed all the time? 0
>> if there is no epoch for that package.
>
> Obviously you CAN, but do you REALLY want to?
Personally, yes. I would like to see epoch listed always so that we get
a consistent format for other scripts to parse.
Scripts can always use "--qf ...". I'd argue that people who use rpm
interactively in most cases don't want to see the epoch prefixed if
there is none. And there is none:
nils@gibraltar:~> rpm -q --qf '%{n}-%{epoch}:%{v}-%{r}.%{arch}\n' initscripts
initscripts-(none):8.60-1.x86_64
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
8:04 a.m.
On Mon, 2007-11-26 at 17:38 +0530, Rahul Sundaram wrote:
Panu Matilainen wrote:
> On Sat, 24 Nov 2007, Rahul Sundaram wrote:
>
>> Panu Matilainen wrote:
>>
>>>
>>> The ugly part is that it makes parsing harder as you have to account
>>> for the possibility of epoch being or not being there always, but
>>> OTOH you can always pick your own queryformat if you don't want to
>>> deal with it.
>>
>> Can't you unconditionally have a epoch number listed all the time? 0
>> if there is no epoch for that package.
>
> Obviously you CAN, but do you REALLY want to?
Personally, yes. I would like to see epoch listed always so that we get
a consistent format for other scripts to parse.
-1 showing the epoch looks ridiculous since in most cases it'll be a 0.
Yum has done this for a long time, actually:
foo-1.1-1.noarch
1:bar-1.1-1.noarch
foo has none or a 0 epoch
bar has an epoch of 1
-sv
8:16 a.m.
On Mon, Nov 26, 2007 at 05:38:55PM +0530, Rahul Sundaram wrote:
Panu Matilainen wrote:
>On Sat, 24 Nov 2007, Rahul Sundaram wrote:
>
>>Panu Matilainen wrote:
>>
>>>
>>>The ugly part is that it makes parsing harder as you have to account
>>>for the possibility of epoch being or not being there always, but
>>>OTOH you can always pick your own queryformat if you don't want to
>>>deal with it.
>>
>>Can't you unconditionally have a epoch number listed all the time? 0
>>if there is no epoch for that package.
>
>Obviously you CAN, but do you REALLY want to?
Personally, yes. I would like to see epoch listed always so that we get
a consistent format for other scripts to parse.
Which would assume those scripts only ever run on Fedora 9 or later.
Any script which wants consistency *HAS* to use an explicit --qf if it wants
to also work on older Fedora, or pretty much any other RPM distro. There's
nothing we can do about this, because its just historical baggage. So
making a change to add Epoch won't help consistency - it'll make it worse,
and it'll also potentially break exisiting scripts not expecting an
Epoch by default.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
5:10 a.m.
On Thu, 22 Nov 2007, Callum Lerwick wrote:
On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> To put it shortly, I going to switch the default rpm queryformat to
> include package architecture (ie what you get now with
> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or
> so.
Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
FWIW, upstream rpm.org now uses this as the default queryformat and
supports it in queries etc:
[pmatilai@localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
gimp-2:2.4.1-1.fc8.x86_64
The epoch is the most significant factor in version comparison, might as
well show it...
- Panu -
5:24 a.m.
On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
On Thu, 22 Nov 2007, Callum Lerwick wrote:
>
> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>> To put it shortly, I going to switch the default rpm queryformat to
>> include package architecture (ie what you get now with
>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days
or
>> so.
>
> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
FWIW, upstream rpm.org now uses this as the default queryformat and
supports it in queries etc:
[pmatilai@localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
gimp-2:2.4.1-1.fc8.x86_64
-1
The epoch is the most significant factor in version comparison, might
as
well show it...
with this queryformat people now will start bitching on why they
can't
find a file of this name - the same applies to "all small letters file
names".
Ralf
5:30 a.m.
On Tue, 27 Nov 2007, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> On Thu, 22 Nov 2007, Callum Lerwick wrote:
>
>>
>> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>>> To put it shortly, I going to switch the default rpm queryformat to
>>> include package architecture (ie what you get now with
>>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few
days or
>>> so.
>>
>> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
>
> FWIW, upstream rpm.org now uses this as the default queryformat and
> supports it in queries etc:
> [pmatilai@localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
> gimp-2:2.4.1-1.fc8.x86_64
-1
> The epoch is the most significant factor in version comparison, might as
> well show it...
with this queryformat people now will start bitching on why they can't
find a file of this name - the same applies to "all small letters file
names".
I'm changing the default filename too to match this, for this very reason.
- Panu -
5:45 a.m.
On Tue, 2007-11-27 at 13:30 +0200, Panu Matilainen wrote:
On Tue, 27 Nov 2007, Ralf Corsepius wrote:
>
> On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
>> On Thu, 22 Nov 2007, Callum Lerwick wrote:
>>
>>>
>>> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>>>> To put it shortly, I going to switch the default rpm queryformat to
>>>> include package architecture (ie what you get now with
>>>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a
few days or
>>>> so.
>>>
>>> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
>>
>> FWIW, upstream rpm.org now uses this as the default queryformat and
>> supports it in queries etc:
>> [pmatilai@localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
>> gimp-2:2.4.1-1.fc8.x86_64
> -1
>
>> The epoch is the most significant factor in version comparison, might as
>> well show it...
> with this queryformat people now will start bitching on why they can't
> find a file of this name - the same applies to "all small letters file
> names".
I'm changing the default filename too to match this, for this very reason.
Pardon, but now you are going too far - You have driven things into
absurdity.
Ralf
6:44 a.m.
On Tue, 27 Nov 2007, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 13:30 +0200, Panu Matilainen wrote:
> On Tue, 27 Nov 2007, Ralf Corsepius wrote:
>
>>
>> On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
>>> On Thu, 22 Nov 2007, Callum Lerwick wrote:
>>>
>>>>
>>>> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>>>>> To put it shortly, I going to switch the default rpm queryformat to
>>>>> include package architecture (ie what you get now with
>>>>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a
few days or
>>>>> so.
>>>>
>>>> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
>>>
>>> FWIW, upstream rpm.org now uses this as the default queryformat and
>>> supports it in queries etc:
>>> [pmatilai@localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
>>> gimp-2:2.4.1-1.fc8.x86_64
>> -1
>>
>>> The epoch is the most significant factor in version comparison, might as
>>> well show it...
>> with this queryformat people now will start bitching on why they can't
>> find a file of this name - the same applies to "all small letters file
>> names".
>
> I'm changing the default filename too to match this, for this very reason.
Pardon, but now you are going too far - You have driven things into
absurdity.
IMO the biggest absurdity here is the traditional behavior of hiding the
epoch. Why should rpm try to [*] hide the most significant factor in it's
version comparison?
[*] The epoch "leaks out" in failed dependency errors, forcing you to
figure out what the heck this X: is and how to query it out of
packages/rpmdb.
- Panu -
6:51 a.m.
On Tuesday 27 November 2007 12:30:19 Panu Matilainen wrote:
On Tue, 27 Nov 2007, Ralf Corsepius wrote:
> On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
>> gimp-2:2.4.1-1.fc8.x86_64
>
> -1
>
>> The epoch is the most significant factor in version comparison, might as
>> well show it...
>
> with this queryformat people now will start bitching on why they can't
> find a file of this name - the same applies to "all small letters file
> names".
I'm changing the default filename too to match this, for this very reason.
Please no. Do not use ":" in filenames. It will prevent a simple backup to a
FAT filesystem.
--
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau
6:59 a.m.
On Tue, Nov 27, 2007 at 01:51:31PM +0100, Laurent Rineau wrote:
On Tuesday 27 November 2007 12:30:19 Panu Matilainen wrote:
> On Tue, 27 Nov 2007, Ralf Corsepius wrote:
> > On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> >> gimp-2:2.4.1-1.fc8.x86_64
> >
> > -1
> >
> >> The epoch is the most significant factor in version comparison, might as
> >> well show it...
> >
> > with this queryformat people now will start bitching on why they can't
> > find a file of this name - the same applies to "all small letters file
> > names".
>
> I'm changing the default filename too to match this, for this very reason.
Please no. Do not use ":" in filenames. It will prevent a simple backup to a
FAT filesystem.
This is not a valid reason. Epoch is essential for dependency
resolution/comparison so that it belongs to filename IMNSHO.
You can tar the rpms to an archive so that you can use FAT fs
for backup.
+1 for epoch in filename/default query format.
Jindrich
--
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
7:25 a.m.
On Tue, 27 Nov 2007 13:59:14 +0100, Jindrich Novy wrote:
Epoch is essential for dependency
resolution/comparison so that it belongs to filename IMNSHO.
Other package details [such as Capabilities, virtual packages, but also
Requires, Conflicts, Obsoletes] are essential, too, but need not pollute
the file name either. Nowadays we have tools to do the resolving.
11:31 a.m.
On Tue, 2007-11-27 at 13:51 +0100, Laurent Rineau wrote:
On Tuesday 27 November 2007 12:30:19 Panu Matilainen wrote:
> On Tue, 27 Nov 2007, Ralf Corsepius wrote:
> > On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> >> gimp-2:2.4.1-1.fc8.x86_64
> >
> > -1
> >
> >> The epoch is the most significant factor in version comparison, might as
> >> well show it...
> >
> > with this queryformat people now will start bitching on why they can't
> > find a file of this name - the same applies to "all small letters file
> > names".
>
> I'm changing the default filename too to match this, for this very reason.
Please no. Do not use ":" in filenames. It will prevent a simple backup to a
FAT filesystem.
I was going to argue that this is about as bogus argument as saying that
we should limit rpm filenames to 8.3. Now I realize that some people,
mostly those without their Fedora boxes connected to Internet,
occassionaly have to download packages on Windows machines in thier
schools, etc.
What's the status of ':' support in windows? Is it possible to use those
characters on NTFS? The file name if a package is not important, unless
you let rpm satisfy dependencies, does it? What happens when you attempt
to download a file with a colon in name in Windows -- does it replace it
with some other character?
If only a dash for chosen as an epoch separator instead of a colon...
--
Lubomir Kundrak (Red Hat Security Response Team)
11:45 a.m.
On Tue, 27 Nov 2007, Lubomir Kundrak wrote:
What's the status of ':' support in windows? Is it
possible to use those
characters on NTFS? The file name if a package is not important, unless
you let rpm satisfy dependencies, does it? What happens when you attempt
to download a file with a colon in name in Windows -- does it replace it
with some other character?
Actually, I tried naming something with a : on someone's XP box yesterday
(totally unrelated to this), and it wouldn't let me. I didn't check, but
I can only imagine it was using NTFS (fairly new machine).
If only a dash for chosen as an epoch separator instead of a colon...
Oh, *that'll* make it more readable. ;-)
Jima
12:04 p.m.
On Tue, 2007-11-27 at 11:45 -0600, Jima wrote:
On Tue, 27 Nov 2007, Lubomir Kundrak wrote:
> What's the status of ':' support in windows? Is it possible to use
those
> characters on NTFS? The file name if a package is not important, unless
> you let rpm satisfy dependencies, does it? What happens when you attempt
> to download a file with a colon in name in Windows -- does it replace it
> with some other character?
Actually, I tried naming something with a : on someone's XP box yesterday
(totally unrelated to this), and it wouldn't let me. I didn't check, but
I can only imagine it was using NTFS (fairly new machine).
> If only a dash for chosen as an epoch separator instead of a colon...
Oh, *that'll* make it more readable. ;-)
Jima, are we talking about readability? Well, then we should exchange
names like orange-devel-0.3-5.cvs20051118.fc8.x86_64.rpm for "Orange
Development Package" and so on. Can you see how nice would they look on
a desktop? ;)
--
Lubomir Kundrak (Red Hat Security Response Team)
12:32 p.m.
On Tue, 27 Nov 2007, Lubomir Kundrak wrote:
Jima, are we talking about readability? Well, then we should
exchange
names like orange-devel-0.3-5.cvs20051118.fc8.x86_64.rpm for "Orange
Development Package" and so on. Can you see how nice would they look on
a desktop? ;)
I wasn't dismissing your suggestion out of hand. (Sorry, I should have
been clearer.) I'd advocate for a different separator if possible, though
(_ maybe?). - is a bit heavily used, appearing in the %name (as many as 5
times!), and as a separator between %name, %version, and %release.
Occasionally, with numbers in %name, it can take a moment to tell where
%name ends and %version begins. :-)
Fortunately, the really unreadable RPM filenames I have an issue with
aren't in Fedora.
Jima
12:33 p.m.
On Tue, 2007-11-27 at 12:32 -0600, Jima wrote:
On Tue, 27 Nov 2007, Lubomir Kundrak wrote:
> Jima, are we talking about readability? Well, then we should exchange
> names like orange-devel-0.3-5.cvs20051118.fc8.x86_64.rpm for "Orange
> Development Package" and so on. Can you see how nice would they look on
> a desktop? ;)
I wasn't dismissing your suggestion out of hand. (Sorry, I should have
been clearer.) I'd advocate for a different separator if possible, though
(_ maybe?). - is a bit heavily used, appearing in the %name (as many as 5
times!), and as a separator between %name, %version, and %release.
Occasionally, with numbers in %name, it can take a moment to tell where
%name ends and %version begins. :-)
Yah - you have to read backward from left to right to parse an rpm
filename into the subcomponents.
here are the steps:
- get rid of .rpm
- read backward until a '.' - that's the arch
- read backward until the next '-' - that's the release
- read backward until the next '-' - that's the version
- read backward until you hit a ':' (if there is one) - that's the name
- read backward until the beginning of the string - that's the epoch
That let's you parse a filename like:
epoch:name-ver-rel.arch.rpm
and it handles -'s in names
if you wanted
name-epoch:ver-rel.arch.rpm you'd just have to make sure that : is
banished from ver and rel and always included.
-sv
12:44 p.m.
On Nov 27, 2007 9:32 AM, Jima <jima(a)beer.tclug.org> wrote:
I wasn't dismissing your suggestion out of hand. (Sorry, I
should have
been clearer.) I'd advocate for a different separator if possible, though
(_ maybe?). - is a bit heavily used, appearing in the %name (as many as 5
times!), and as a separator between %name, %version, and %release.
Occasionally, with numbers in %name, it can take a moment to tell where
%name ends and %version begins. :-)
Fortunately, the really unreadable RPM filenames I have an issue with
aren't in Fedora.
Honestly since - is overused already, its not going to hurt legibility
anymore by reusing it again. If we were going to enforce legibility
we would have a specific character designated as a field separator and
forbid it to be used in any tag field.
Doesn't the extended ascii character set include a smiley face up in
the table near the end? We could use that.. or maybe we could use the
ascii 1/2 character as the field seperator
-jef"name(ascii:204)epoch(ascii:199)version(ascii:197)release(ascii:182)arch(ascii:236)"spaleta
1:26 p.m.
Le mardi 27 novembre 2007 à 09:44 -0900, Jeff Spaleta a écrit :
Doesn't the extended ascii character set include a smiley face up
in
the table near the end? We could use that.. or maybe we could use the
ascii 1/2 character as the field seperator
-jef"name(ascii:204)epoch(ascii:199)version(ascii:197)release(ascii:182)arch(ascii:236)"spaleta
Official Fedora encoding is UTF-8, and ascii>127 makes no sense
--
Nicolas Mailhot
11:58 a.m.
Le mardi 27 novembre 2007 à 18:31 +0100, Lubomir Kundrak a écrit :
What's the status of ':' support in windows?
It's a forbidden character. Windows won't let you use it and refuse
files with : inside.
There are many other possible separators, though so blocking on : is
stupid.
--
Nicolas Mailhot
12:02 p.m.
On Tuesday 27 November 2007 18:31:28 Lubomir Kundrak wrote:
On Tue, 2007-11-27 at 13:51 +0100, Laurent Rineau wrote:
> Please no. Do not use ":" in filenames. It will prevent a simple backup
> to a FAT filesystem.
I was going to argue that this is about as bogus argument as saying that
we should limit rpm filenames to 8.3.
8.3 is a pre-FAT32 limitation. Since Windows XP, everybody uses FAT32 instead
of the old FAT (even Windows 95 can read and write to FAT32).
What's the status of ':' support in windows? Is it
possible to use those
characters on NTFS?
NTFS allows the use of ":" (only the null character and "/" is
disallowed.
However, the Win32 API does not permit the use of ":".
The file name if a package is not important, unless
you let rpm satisfy dependencies, does it? What happens when you attempt
to download a file with a colon in name in Windows -- does it replace it
with some other character?
I do not know.
--
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau
12:18 a.m.
Dnia 2007-11-27, o godz. 19:02:11 Laurent Rineau
<laurent.rineau__fedora(a)normalesup.org> napisał(a):
8.3 is a pre-FAT32 limitation. Since Windows XP, everybody uses
FAT32
instead of the old FAT (even Windows 95 can read and write to FAT32).
You're
confusing FAT32 with VFAT.
Lam
2:48 a.m.
On Wednesday 28 November 2007 07:18:57 Leszek Matok wrote:
Dnia 2007-11-27, o godz. 19:02:11 Laurent Rineau
<laurent.rineau__fedora(a)normalesup.org> napisał(a):
> 8.3 is a pre-FAT32 limitation. Since Windows XP, everybody uses FAT32
> instead of the old FAT (even Windows 95 can read and write to FAT32).
You're confusing FAT32 with VFAT.
I have simplified, intentionally.
--
Laurent Rineau
http://fedoraproject.org/wiki/LaurentRineau
1:17 p.m.
On Tue, Nov 27, 2007 at 01:30:19PM +0200, Panu Matilainen wrote:
On Tue, 27 Nov 2007, Ralf Corsepius wrote:
>with this queryformat people now will start bitching on why they can't
>find a file of this name - the same applies to "all small letters file
>names".
I'm changing the default filename too to match this, for this very reason.
Hmm, this makes bash completion a bit akward as $COMP_WORDBREAKS
contains a ':'. I.e., foo-3:2<TAB> doesn't complete the rpm name
any longer.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
2:34 p.m.
On Tue, 27 Nov 2007, Michael Schroeder wrote:
On Tue, Nov 27, 2007 at 01:30:19PM +0200, Panu Matilainen wrote:
> On Tue, 27 Nov 2007, Ralf Corsepius wrote:
>> with this queryformat people now will start bitching on why they can't
>> find a file of this name - the same applies to "all small letters file
>> names".
>
> I'm changing the default filename too to match this, for this very reason.
Hmm, this makes bash completion a bit akward as $COMP_WORDBREAKS
contains a ':'. I.e., foo-3:2<TAB> doesn't complete the rpm name
any longer.
Right, that's fairly nasty, and also I think the first practical "this
breaks" example instead of "somebodys hypotethical script somewhere" cases
(which without doubt do exist). Backing up to filesystem X where ':' is
illegal doesn't really count as reason though, as ':' is a valid character
in rpm otherwise anyway.
The point of the excercise (in rpm.org HEAD) was largely to see what would
really break but I think I've seen enough already. So back to plan A)
which was
- add arch to default queryformat
- add popt-alias for legacy nvr queryformat
- add popt-alias for nevra queryformat to make accessing the "hidden"
epoch info saner than a mile-long queryformat strings
I guess that's enough excitement for one-time change in the world of RPM,
and now off to revert the changes, mark for revisiting in ten years...
At least this was a fairly entertaining day on fedora-devel ;)
- Panu -
2:40 p.m.
On Tue, Nov 27, 2007 at 10:34:31PM +0200, Panu Matilainen wrote:
Right, that's fairly nasty, and also I think the first practical
"this
breaks" example instead of "somebodys hypotethical script somewhere" cases
(which without doubt do exist).
If you want some other example where things might break:
$ scp foo-2:1-1.noarch.rpm someotherhost:/tmp
ssh: foo-2: Name or service not known
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
6:53 a.m.
On Tue, 27 Nov 2007 12:24:18 +0100, Ralf Corsepius wrote:
On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> On Thu, 22 Nov 2007, Callum Lerwick wrote:
>
> >
> > On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> >> To put it shortly, I going to switch the default rpm queryformat to
> >> include package architecture (ie what you get now with
> >> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few
days or
> >> so.
> >
> > Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
>
> FWIW, upstream rpm.org now uses this as the default queryformat and
> supports it in queries etc:
> [pmatilai@localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
> gimp-2:2.4.1-1.fc8.x86_64
-1
Oh, yes, add my -1 here, too. Epoch is implicit in versioned requirements [1],
so please don't make it explicit in file names. This only pours gasoline
into the fire. RPM dependency hell is back, stronger than ever.
> The epoch is the most significant factor in version comparison,
might as
> well show it...
with this queryformat people now will start bitching on why they can't
find a file of this name - the same applies to "all small letters file
names".
This is half-baked so far and only adds a lot of confusion.
--
[1] Requires: foo > 4.0 and foo-1:0.9-1.fc8.noarch.rpm is sufficient.
8:20 a.m.
On Tue, 2007-11-27 at 13:53 +0100, Michael Schwendt wrote:
On Tue, 27 Nov 2007 12:24:18 +0100, Ralf Corsepius wrote:
>
> On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
> > On Thu, 22 Nov 2007, Callum Lerwick wrote:
> >
> > >
> > > On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
> > >> To put it shortly, I going to switch the default rpm queryformat to
> > >> include package architecture (ie what you get now with
> > >> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a
few days or
> > >> so.
> > >
> > > Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
> >
> > FWIW, upstream rpm.org now uses this as the default queryformat and
> > supports it in queries etc:
> > [pmatilai@localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
> > gimp-2:2.4.1-1.fc8.x86_64
> -1
Oh, yes, add my -1 here, too. Epoch is implicit in versioned requirements [1],
so please don't make it explicit in file names. This only pours gasoline
into the fire. RPM dependency hell is back, stronger than ever.
For what its worth, I agree. Epoch in the file name is a bad idea.
~spot
8:59 a.m.
On Tue, 27 Nov 2007, Tom \spot\ Callaway wrote:
On Tue, 2007-11-27 at 13:53 +0100, Michael Schwendt wrote:
> On Tue, 27 Nov 2007 12:24:18 +0100, Ralf Corsepius wrote:
>
>>
>> On Tue, 2007-11-27 at 13:10 +0200, Panu Matilainen wrote:
>>> On Thu, 22 Nov 2007, Callum Lerwick wrote:
>>>
>>>>
>>>> On Wed, 2007-11-21 at 10:49 +0200, Panu Matilainen wrote:
>>>>> To put it shortly, I going to switch the default rpm queryformat to
>>>>> include package architecture (ie what you get now with
>>>>> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a
few days or
>>>>> so.
>>>>
>>>> Not %{name}-%|epoch?{%{epoch}:}|%{version}-%{release}.%{arch} ? :)
>>>
>>> FWIW, upstream rpm.org now uses this as the default queryformat and
>>> supports it in queries etc:
>>> [pmatilai@localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
>>> gimp-2:2.4.1-1.fc8.x86_64
>> -1
>
> Oh, yes, add my -1 here, too. Epoch is implicit in versioned requirements [1],
> so please don't make it explicit in file names. This only pours gasoline
> into the fire. RPM dependency hell is back, stronger than ever.
For what its worth, I agree. Epoch in the file name is a bad idea.
Why do you think it's bad - because of the ':' used as separator, or
"just because" (epochs are evil and all that)?
Currently you can store different versions and releases of a package
within a directory without them clashing - why is it ok for packages with
different epochs to clash in that situation?
- Panu -
9:09 a.m.
On Tue, 2007-11-27 at 16:59 +0200, Panu Matilainen wrote:
> For what its worth, I agree. Epoch in the file name is a bad
idea.
Why do you think it's bad - because of the ':' used as separator, or
"just because" (epochs are evil and all that)?
Currently you can store different versions and releases of a package
within a directory without them clashing - why is it ok for packages with
different epochs to clash in that situation?
Well, using : as a separator seems like a bad idea, but I really don't
want to encourage epoch use. Its a last resort hack to fix a broken
package when there is no other way to ensure safe upgrades. If new
packagers start seeing it show up in a far more visible way, people will
think that they need to use it by default.
~spot
9:19 a.m.
On Tue, 27 Nov 2007, Tom \spot\ Callaway wrote:
On Tue, 2007-11-27 at 16:59 +0200, Panu Matilainen wrote:
>> For what its worth, I agree. Epoch in the file name is a bad idea.
>
> Why do you think it's bad - because of the ':' used as separator, or
> "just because" (epochs are evil and all that)?
>
> Currently you can store different versions and releases of a package
> within a directory without them clashing - why is it ok for packages with
> different epochs to clash in that situation?
Well, using : as a separator seems like a bad idea, but I really don't
want to encourage epoch use. Its a last resort hack to fix a broken
package when there is no other way to ensure safe upgrades. If new
packagers start seeing it show up in a far more visible way, people will
think that they need to use it by default.
If limiting visibility of the epochs is the argument, then why is it ok
for end user tools such as pirut (not to mention yum itself and all
related tools) to show them?
- Panu -
9:24 a.m.
On Tue, Nov 27, 2007 at 05:19:15PM +0200, Panu Matilainen wrote:
>Well, using : as a separator seems like a bad idea, but I really
don't
>want to encourage epoch use. Its a last resort hack to fix a broken
>package when there is no other way to ensure safe upgrades. If new
>packagers start seeing it show up in a far more visible way, people will
>think that they need to use it by default.
If limiting visibility of the epochs is the argument, then why is it ok
for end user tools such as pirut (not to mention yum itself and all
related tools) to show them?
I agree. If limiting epoch visibility is the argument, we should be
showing them in the low-level tools (rpm, yum) but not the high-level
tools (pirut, pup). Not that I agree that we should be limiting their
visibility at all.
9:28 a.m.
On Tue, 27 Nov 2007, Panu Matilainen wrote:
If limiting visibility of the epochs is the argument, then why is it
ok for
end user tools such as pirut (not to mention yum itself and all related
tools) to show them?
gui tools != *nix pipeline tools -- if this is an unknown
distinction, we are all doomed.
Epoch, like or not, has a checkered history; Arch is even
stinkier with multilib.
Change the silly default macro if one wishes, but be prepared
to support explaining why it is different for many years to
come.
Heavens, we still see questions about the rpm -ba -> rpmbuild
transition, 5 years later.
-- Russ Herrold
12:25 p.m.
On Nov 27, 2007 6:19 AM, Panu Matilainen <pmatilai(a)laiskiainen.org> wrote:
If limiting visibility of the epochs is the argument, then why is it
ok
for end user tools such as pirut (not to mention yum itself and all
related tools) to show them?
Putting the epoch into the filename output as the second most
significant piece of information will be more disruptive to shell
scriptable interactions than tacking on the arch at the end. Putting
the information into an interactive interface that people do not
commonly rely on in a scripted way is far less disruptive.
I'm not going to judge whether or not its worth doing, but I'm telling
you right now that there will a large need for a re-education program
concerning the epoch information if it goes in. We'll need you to blog
about it preemptively and possibly provide some information in the
form of a feature item, such as how to revert this change for legacy
needs, information that documentation writers can reformat and
distribute as needed.
Also it would be instructive to know if such a change is planned to be
propagated forward into the next RHEL release.
Please consider something other than the colon character as a
separator so we don't disrupt the ability to backup rpm package files
into fat filesystems. There are a lot of external enclosures out
there with big disks with fat filesystems being used for backups in
small IT situations (home office, personal use and things of that
nature.) Making a filenaming change which disrupts the ability to
backup the files seems an unnecessary complication.
-jef
1:19 p.m.
Jeff Spaleta wrote:
Putting the epoch into the filename output as the second most
significant piece of information will be more disruptive to shell
scriptable interactions than tacking on the arch at the end.
Putting the information into an interactive interface that people do
not commonly rely on in a scripted way is far less disruptive.
Anyone that's parsing rpm output in a script should have been using
the --qf option a long time ago to ensure that they get the output
they want, really.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Women should be obscene and not heard.
-- Groucho Marx
1:39 p.m.
On Nov 27, 2007 10:19 AM, Todd Zullinger <tmz(a)pobox.com> wrote:
Anyone that's parsing rpm output in a script should have been
using
the --qf option a long time ago to ensure that they get the output
they want, really.
The --qf option even for uninstall package files sitting on a
filesystem which may or may not be mounted on an operating system with
rpm available but is accessible via the network for rpm using system
to pull from?
We can should ourselves until we are blue in the face and tsk tsk
people for not using the qf mechanism appropriately with scripted rpm
queries... but we'll still need to make a polite effort to re-educate
the people who are relying on the default structure of string.
I'm not saying this as an argument against doing it. I'm saying when
you do it, it will be relatively more painful to add a new epoch field
internal to the string than tacking on information at the end of the
querystring AND the package filename. We should make a vocal
preemptive effort to get the word out before this lands in a release
to take the edge off the disgruntled bloodlust for making a change.
There is discussion in this thread about changing the filename as well
as the rpmdb querystring to be self-consistent in terms of displaying
the epoch. Any scripting against package filenames will be disrupted
by a new epoch field and I think that deserves some effort to raise
awareness sooner rather than later.
-jef
8:06 p.m.
Jeff Spaleta wrote:
I'm not saying this as an argument against doing it. I'm
saying when
you do it, it will be relatively more painful to add a new epoch field
internal to the string than tacking on information at the end of the
querystring AND the package filename. We should make a vocal
preemptive effort to get the word out before this lands in a release
to take the edge off the disgruntled bloodlust for making a change.
There is discussion in this thread about changing the filename as well
as the rpmdb querystring to be self-consistent in terms of displaying
the epoch. Any scripting against package filenames will be disrupted
by a new epoch field and I think that deserves some effort to raise
awareness sooner rather than later.
-jef
This is an incredibly important point for everyone to stand back and think
through... the people this kind of 'small and relatively innocuous' change
effects are NOT all reading this list and commenting. They are the people who
have no idea the change is coming, and won't notice until to their amazement its
breaking their previously working custom scripts in their own little lab
environment, etc.
'How much can an epoch in filenames hurt'? Thats hard to say. What does it
solve? Nothing that everyone isn't already used to dealing with.
--
Andrew Farris <lordmorgul(a)gmail.com> <ajfarris(a)gmail.com>
gpg 0xC99B1DF3 at pgp.mit.edu
No one now has, and no one will ever again get, the big picture. - Daniel Geer
---- ----
10:12 a.m.
On Tue, 27 Nov 2007 16:59:59 +0200 (EET), Panu Matilainen wrote:
>>>> FWIW, upstream rpm.org now uses this as the default
queryformat and
>>>> supports it in queries etc:
>>>> [pmatilai@localhost rpm]$ ./rpmq -q gimp-2:2.4.1-1.fc8.x86_64
>>>> gimp-2:2.4.1-1.fc8.x86_64
>>> -1
>>
>> Oh, yes, add my -1 here, too. Epoch is implicit in versioned requirements [1],
>> so please don't make it explicit in file names. This only pours gasoline
>> into the fire. RPM dependency hell is back, stronger than ever.
>
> For what its worth, I agree. Epoch in the file name is a bad idea.
Why do you think it's bad - because of the ':' used as separator, or
"just because" (epochs are evil and all that)?
Currently you can store different versions and releases of a package
within a directory without them clashing - why is it ok for packages with
different epochs to clash in that situation?
Because no packager should ever bump %epoch without bumping %release.
Rule of thumb: New build => new release.
And yes, if %version changes, you update (i.e. reset) %release, too,
usually.
10:29 a.m.
On Tue, 27 Nov 2007 17:12:38 +0100
Michael Schwendt <mschwendt.tmp0701.nospam(a)arcor.de> wrote:
Because no packager should ever bump %epoch without bumping
%release.
Rule of thumb: New build => new release.
In fact, koji enforces this. Koji stores builds based on n-v-r, not
n-e-v-r, so if you only just bump epoch, koji will give you an error.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
4:43 a.m.
On Tue, 2007-11-27 at 11:29 -0500, Jesse Keating wrote:
On Tue, 27 Nov 2007 17:12:38 +0100
Michael Schwendt <mschwendt.tmp0701.nospam(a)arcor.de> wrote:
> Because no packager should ever bump %epoch without bumping %release.
> Rule of thumb: New build => new release.
In fact, koji enforces this. Koji stores builds based on n-v-r, not
n-e-v-r, so if you only just bump epoch, koji will give you an error.
Psst. That isn't something I would tout as a feature ;-).
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little
Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
5:47 a.m.
On Wed, 28 Nov 2007 11:43:47 +0100
Nils Philippsen <nphilipp(a)redhat.com> wrote:
> In fact, koji enforces this. Koji stores builds based on n-v-r,
not
> n-e-v-r, so if you only just bump epoch, koji will give you an
> error.
Psst. That isn't something I would tout as a feature ;-).
It is. This was a very intentional design item. We wanted to make
sure that when a maintainer bumped epoch, they /had/ to bump something
else of nvr with it.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
9:28 a.m.
On Wed, 2007-11-28 at 06:47 -0500, Jesse Keating wrote:
On Wed, 28 Nov 2007 11:43:47 +0100
Nils Philippsen <nphilipp(a)redhat.com> wrote:
> > In fact, koji enforces this. Koji stores builds based on n-v-r, not
> > n-e-v-r, so if you only just bump epoch, koji will give you an
> > error.
>
> Psst. That isn't something I would tout as a feature ;-).
It is. This was a very intentional design item. We wanted to make
sure that when a maintainer bumped epoch, they /had/ to bump something
else of nvr with it.
Well, that probably works for situations where the epoch was a result of
sloppy packaging. If an epoch is needed because upstream "rebases"
versions (or upstream is "rebased" -- due to a forked project or
whatever), it's going to be much fun for the maintainer if/when the
versions clash with the old numberspace.
What is the reasoning for needing to bump something else beside the
epoch? As far as I'm concerned, epoch is the most significant part of
the "combined version" of a package -- isn't that the case?
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
9:33 a.m.
On Wed, 28 Nov 2007 16:28:59 +0100
Nils Philippsen <nphilipp(a)redhat.com> wrote:
Well, that probably works for situations where the epoch was a
result
of sloppy packaging. If an epoch is needed because upstream "rebases"
versions (or upstream is "rebased" -- due to a forked project or
whatever), it's going to be much fun for the maintainer if/when the
versions clash with the old numberspace.
What is the reasoning for needing to bump something else beside the
epoch? As far as I'm concerned, epoch is the most significant part of
the "combined version" of a package -- isn't that the case?
The most basic example, if you just bump epoch and nothing else, the
resultant file name is no different than the previous file name. You
can't store the two builds in the same directory, and it's quite
confusing.
There are more, but flip it on it's head. Why would you ever /only/
bump the epoch and not also bump at least the release number? Release
is something we as a vendor control, which is our added numbering on
top of upstream's numbering. You wouldn't have to change version, just
release.
--
Jesse Keating
Fedora -- All my bits are free, are yours?
11:52 a.m.
On Wed, 28 Nov 2007, Jesse Keating wrote:
Nils Philippsen <nphilipp(a)redhat.com> wrote:
> What is the reasoning for needing to bump something else beside the
> epoch? As far as I'm concerned, epoch is the most significant part of
> the "combined version" of a package -- isn't that the case?
The most basic example, if you just bump epoch and nothing else, the
resultant file name is no different than the previous file name. You
can't store the two builds in the same directory, and it's quite
confusing.
More importantly, wouldn't the CVS tag be the same, too? That's a big
show-stopper.
Jima
2:53 a.m.
On Wed, 2007-11-28 at 11:52 -0600, Jima wrote:
On Wed, 28 Nov 2007, Jesse Keating wrote:
> Nils Philippsen <nphilipp(a)redhat.com> wrote:
>> What is the reasoning for needing to bump something else beside the
>> epoch? As far as I'm concerned, epoch is the most significant part of
>> the "combined version" of a package -- isn't that the case?
>
> The most basic example, if you just bump epoch and nothing else, the
> resultant file name is no different than the previous file name. You
> can't store the two builds in the same directory, and it's quite
> confusing.
More importantly, wouldn't the CVS tag be the same, too? That's a big
show-stopper.
I'd rather buy Jesse's filename argument -- (CVS) tags can be changed,
as can tagging schemes.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
9:38 a.m.
On Thu, 29 Nov 2007, Nils Philippsen wrote:
On Wed, 2007-11-28 at 11:52 -0600, Jima wrote:
> On Wed, 28 Nov 2007, Jesse Keating wrote:
>> The most basic example, if you just bump epoch and nothing else, the
>> resultant file name is no different than the previous file name. You
>> can't store the two builds in the same directory, and it's quite
>> confusing.
>
> More importantly, wouldn't the CVS tag be the same, too? That's a big
> show-stopper.
I'd rather buy Jesse's filename argument -- (CVS) tags can be changed,
as can tagging schemes.
IIRC, you can't re-use a CVS tag once Koji's interacted with it, but in
regard to changing the tagging _scheme_, yes, that could be done.
Jima
11:31 a.m.
Panu Matilainen (pmatilai(a)laiskiainen.org) said:
Why do you think it's bad - because of the ':' used as
separator, or "just
because" (epochs are evil and all that)?
It uses a valid release character as a separator between epoch and
release, making parsing without reading the header more 'interesting',
without knowing which version of RPM created the file.
Bill
1:44 p.m.
On Tue, 27 Nov 2007, Bill Nottingham wrote:
Panu Matilainen (pmatilai(a)laiskiainen.org) said:
> Why do you think it's bad - because of the ':' used as separator, or
"just
> because" (epochs are evil and all that)?
It uses a valid release character as a separator between epoch and
release,
Mm.. urgh, rpm actually accepts ':' in both version and release strings.
making parsing without reading the header more
'interesting',
without knowing which version of RPM created the file.
Make that "without knowing what kind of configuration was this RPM created
with" or "without knowing if 'mv' was used after package creation.
Remember, the filename has zero guarantee to have any resemblance on the
package contents. The output filename is configurable already, has
"always" been, so the n-v-r.arch.rpm format is just a defacto standard.
- Panu -
2:15 p.m.
Panu Matilainen (pmatilai(a)laiskiainen.org) said:
> It uses a valid release character as a separator between epoch
and
> release,
Mm.. urgh, rpm actually accepts ':' in both version and release strings.
And '\0', and ☠, and ⽍, and...
> making parsing without reading the header more
'interesting',
> without knowing which version of RPM created the file.
Make that "without knowing what kind of configuration was this RPM created
with" or "without knowing if 'mv' was used after package creation.
Remember, the filename has zero guarantee to have any resemblance on the
package contents. The output filename is configurable already, has "always"
been, so the n-v-r.arch.rpm format is just a defacto standard.
Sure, but just because it's a de facto rather than de jure standard doesn't
make it any better of an idea to change it.
Bill
9:04 a.m.
Panu Matilainen wrote:
To put it shortly, I going to switch the default rpm queryformat to
include package architecture (ie what you get now with
rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days or so.
This is something that should've been done several releases ago really,
but since it presumably breaks all sorts of scripts people have it's
gotten delayed and delayed... The next major rpm.org release changes the
default anyway, this is just an initial step to see what breaks.
If you know the change would break some of the buildsystem / other
critical Fedora infrastructure, please holler NOW! I can delay the
change a bit to allow critical pieces to be fixed first, but F9 *will*
have the new queryformat so better prepare for it...
Fixing any scripts that absolutely rely on the old default is trivial:
just them use explicit --qf "%{name}-%{version}-%{release}"
My faith in the Flying Spaghetti Monster has paid off. My prayers have
finally been answered!
--
Mike A. Harris
Come and join us on the #fedora8 IRC help forum on irc.freenode.net
9:37 a.m.
Mike A. Harris wrote:
Panu Matilainen wrote:
>
> To put it shortly, I going to switch the default rpm queryformat to
> include package architecture (ie what you get now with
> rpm -q --qf "%{name}-%{version}-%{release}.%{arch}\n") in a few days
> or so.
>
> This is something that should've been done several releases ago
> really, but since it presumably breaks all sorts of scripts people
> have it's gotten delayed and delayed... The next major rpm.org release
> changes the default anyway, this is just an initial step to see what
> breaks.
>
> If you know the change would break some of the buildsystem / other
> critical Fedora infrastructure, please holler NOW! I can delay the
> change a bit to allow critical pieces to be fixed first, but F9 *will*
> have the new queryformat so better prepare for it...
>
> Fixing any scripts that absolutely rely on the old default is trivial:
> just them use explicit --qf "%{name}-%{version}-%{release}"
My faith in the Flying Spaghetti Monster has paid off. My prayers have
finally been answered!
/me sends Mike a stack of Diet Coke for his Spaghetti.
And to topic: +1!!one!eleven!1!!!
Read ya, Phil
--
Philipp Knirsch | Tel.: +49-711-96437-470
Team Lead Core Services | Fax.: +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch <pknirsch(a)redhat.com>
Hauptstaetterstr. 58 | Web: http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd: You're only jealous cos the little penguins are talking to me.
5993
days inactive
6001
days old
66 comments
33 participants
participants (33)
-
Andrew Farris -
Bill Nottingham -
Callum Lerwick -
Christopher Aillon -
Chuck Anderson -
Daniel P. Berrange -
drago01 -
Gilboa Davara -
Hans de Goede -
Ian Burrell -
Ignacio Vazquez-Abrams -
Jef Spaleta -
Jesse Keating -
Jima -
Jindrich Novy -
Laurent Rineau -
Leszek Matok -
Lubomir Kundrak -
Michael Schroeder -
Michael Schwendt -
Mike A. Harris -
Nicolas Mailhot -
Nils Philippsen -
nodata -
Panu Matilainen -
Phil Knirsch -
R P Herrold -
Rahul Sundaram -
Ralf Corsepius -
Seth Vidal -
Thorsten Leemhuis -
Todd Zullinger -
Tom Callaway