9:47 p.m.
Colin Walters mentioned on irc reducing the changelogs kept in pkgs a
bit to help us fit on the livecd a bit better. I didn't really believe
it would make enough of an impact to be noticeable but I did a little
mucking about and found I was wrong. So I wrote this:
http://skvidal.fedorapeople.org/changelog/changelog-sizes.py
It'll dump out 4 files:
- old-repo.txt : changelogs from the pkgs in the repos where the
changelog entry is > 1yr old
- new-repo.txt : changelogs from the pkgs in the repos where the
changelog entry is < 1yr old
- old-db.txt : changelogs from the pkgs in the rpmdb where the changelog
entry is > 1yr old
- new-db.txt : changelogs from the pkgs in the rpmdb where the changelog
entry is < 1yr old
On a mostly-rawhide system with rawhide repos I found:
8157 pkgs in rawhide repos:
new changelogs: 12M
old changelogs: 31M
on my system 1128 packages installed:
new changelogs: 2.2M
old changelogs: 8.6M
That may not seem like much but when we're squinched for space in 700M
on a livecd that 8.6M might be all that's needed. Moreover it may be a
bit silly to be carting all of this history around in all the pkgs and
repodata and in the rpmdb. Esp if we're trying to trim download sizes
for various items. So things we can do:
1. trim the changelogs at createrepo-runtime - fine - but that only gets
it for the repodata
2. trim repos at rpmbuild time - great - I've suggested it as an option
to rpmbuild on rpm-maint list.
3. trim them out of the pkgs the next time we change a package. Just
prune them down to the last years worth of changelogs - maybe saving the
old changelogs in a file in the cvs repository - or even into an unused
source file in the srpm?
What're people's thoughts on this?
-sv
9:58 p.m.
seth vidal wrote, at 08/31/2007 11:47 AM +9:00:
Colin Walters mentioned on irc reducing the changelogs kept in pkgs
a
bit to help us fit on the livecd a bit better. I didn't really believe
it would make enough of an impact to be noticeable but I did a little
mucking about and found I was wrong. So I wrote this:
http://skvidal.fedorapeople.org/changelog/changelog-sizes.py
That may not seem like much but when we're squinched for space in 700M
on a livecd that 8.6M might be all that's needed. Moreover it may be a
bit silly to be carting all of this history around in all the pkgs and
repodata and in the rpmdb. Esp if we're trying to trim download sizes
for various items. So things we can do:
1. trim the changelogs at createrepo-runtime - fine - but that only gets
it for the repodata
2. trim repos at rpmbuild time - great - I've suggested it as an option
to rpmbuild on rpm-maint list.
3. trim them out of the pkgs the next time we change a package. Just
prune them down to the last years worth of changelogs - maybe saving the
old changelogs in a file in the cvs repository - or even into an unused
source file in the srpm?
What're people's thoughts on this?
Just note that this is once discussed on:
http://www.redhat.com/archives/rhl-devel-list/2007-May/msg01646.html
(I guess no conclusion was made though).
Regards,
Mamoru
10:08 p.m.
On Fri, 2007-08-31 at 11:58 +0900, Mamoru Tasaka wrote:
seth vidal wrote, at 08/31/2007 11:47 AM +9:00:
> Colin Walters mentioned on irc reducing the changelogs kept in pkgs a
> bit to help us fit on the livecd a bit better. I didn't really believe
> it would make enough of an impact to be noticeable but I did a little
> mucking about and found I was wrong. So I wrote this:
>
> http://skvidal.fedorapeople.org/changelog/changelog-sizes.py
>
> That may not seem like much but when we're squinched for space in 700M
> on a livecd that 8.6M might be all that's needed. Moreover it may be a
> bit silly to be carting all of this history around in all the pkgs and
> repodata and in the rpmdb. Esp if we're trying to trim download sizes
> for various items. So things we can do:
>
> 1. trim the changelogs at createrepo-runtime - fine - but that only gets
> it for the repodata
>
> 2. trim repos at rpmbuild time - great - I've suggested it as an option
> to rpmbuild on rpm-maint list.
>
> 3. trim them out of the pkgs the next time we change a package. Just
> prune them down to the last years worth of changelogs - maybe saving the
> old changelogs in a file in the cvs repository - or even into an unused
> source file in the srpm?
>
> What're people's thoughts on this?
Just note that this is once discussed on:
http://www.redhat.com/archives/rhl-devel-list/2007-May/msg01646.html
(I guess no conclusion was made though).
You're right - no conclusion - but I guess I should put this to the
packaging committee to get it added to the criteria - if we nuke
everything but the last years worth from the %changelog and we do that
as something useful to do for every release - then we'll be able to keep
it pruned down and we'll still keep the history.
People on the packaging committe - does that sound fair?
-sv
11:29 p.m.
seth vidal wrote:
You're right - no conclusion - but I guess I should put this to
the
packaging committee to get it added to the criteria - if we nuke
everything but the last years worth from the %changelog and we do that
as something useful to do for every release - then we'll be able to keep
it pruned down and we'll still keep the history.
People on the packaging committe - does that sound fair?
-sv
I'm always worried about making it harder to get the history related to
the running code... (I guess there's still always cvs history, but...)
I'd like to see all changelog entries remain that are related to patches
still carried in the src.rpm - and not thrown away just because that
patch was added > 1 year ago. Much harder to automate, though... If
there's a policy that says I can trim my own changelogs with that
criteria, I'll gladly do it. (Maybe the automated trimmer could only
nuke old changelog entries if the changelog is above a certain size
threshold?)
-Eric
11:55 p.m.
On Thu, 2007-08-30 at 23:29 -0500, Eric Sandeen wrote:
seth vidal wrote:
> You're right - no conclusion - but I guess I should put this to the
> packaging committee to get it added to the criteria - if we nuke
> everything but the last years worth from the %changelog and we do that
> as something useful to do for every release - then we'll be able to keep
> it pruned down and we'll still keep the history.
>
> People on the packaging committe - does that sound fair?
>
> -sv
I'm always worried about making it harder to get the history related to
the running code... (I guess there's still always cvs history, but...)
I'd like to see all changelog entries remain that are related to patches
still carried in the src.rpm - and not thrown away just because that
patch was added > 1 year ago. Much harder to automate, though... If
there's a policy that says I can trim my own changelogs with that
criteria, I'll gladly do it. (Maybe the automated trimmer could only
nuke old changelog entries if the changelog is above a certain size
threshold?)
So my first question is this: Why are we carrying a patch for >1yr?
Shouldn't it be being pushed to upstream?
My only problem with letting the changelogs be cherry picked like this
is b/c it is would be hard for people to know when to look elsewhere.
Having the changelog difference be a hard number relative to the latest
date in the package changelog would make it more consistent to know when
to look elsewhere.
Having a consistent location for what is 'elsewhere' is probably also
good.
-sv
12:03 a.m.
seth vidal wrote:
On Thu, 2007-08-30 at 23:29 -0500, Eric Sandeen wrote:
> seth vidal wrote:
>
>> You're right - no conclusion - but I guess I should put this to the
>> packaging committee to get it added to the criteria - if we nuke
>> everything but the last years worth from the %changelog and we do that
>> as something useful to do for every release - then we'll be able to keep
>> it pruned down and we'll still keep the history.
>>
>> People on the packaging committe - does that sound fair?
>>
>> -sv
> I'm always worried about making it harder to get the history related to
> the running code... (I guess there's still always cvs history, but...)
>
> I'd like to see all changelog entries remain that are related to patches
> still carried in the src.rpm - and not thrown away just because that
> patch was added > 1 year ago. Much harder to automate, though... If
> there's a policy that says I can trim my own changelogs with that
> criteria, I'll gladly do it. (Maybe the automated trimmer could only
> nuke old changelog entries if the changelog is above a certain size
> threshold?)
So my first question is this: Why are we carrying a patch for >1yr?
Shouldn't it be being pushed to upstream?
What if upstream is releasing slowly? There may be other valid reasons.
(there may be lots of bad reasons too)
-Eric
12:35 a.m.
On Fri, 2007-08-31 at 00:03 -0500, Eric Sandeen wrote:
What if upstream is releasing slowly? There may be other valid
reasons.
(there may be lots of bad reasons too)
You have a fair point - there are exceptions where this is the suck.
However, consistency in finding the old changelogs make it at least an
easy FAQ.
-sv
12:12 a.m.
seth vidal wrote, at 08/31/2007 01:55 PM +9:00:
On Thu, 2007-08-30 at 23:29 -0500, Eric Sandeen wrote:
> seth vidal wrote:
>
>> People on the packaging committe - does that sound fair?
>>
>> -sv
> I'm always worried about making it harder to get the history related to
> the running code... (I guess there's still always cvs history, but...)
>
> I'd like to see all changelog entries remain that are related to patches
> still carried in the src.rpm - and not thrown away just because that
> patch was added > 1 year ago.
So my first question is this: Why are we carrying a patch for >1yr?
Shouldn't it be being pushed to upstream?
I guess there are some cases where Fedora maintainers sent patches to
upstream but upstream developer refused to apply them.
For xscreensaver (which I maintain) there is a patch "sanitize-hacks.patch"
to rename some screensaver hack. This patch has been renamed several times
(according to the version), but the changelog says that first version of
this patch was introduced 3 years ago (with reflecting:
http://www.redhat.com/archives/fedora-list/2004-August/msg00848.html )
AFAIK, the reply of the upstream was "Well, I can understand Fedora wants to
apply the patch, but I don't think the patch is needed even for non-Fedora
people".
Regard,
Mamoru
12:36 a.m.
On Fri, 2007-08-31 at 00:55 -0400, seth vidal wrote:
On Thu, 2007-08-30 at 23:29 -0500, Eric Sandeen wrote:
> seth vidal wrote:
>
> > You're right - no conclusion - but I guess I should put this to the
> > packaging committee to get it added to the criteria - if we nuke
> > everything but the last years worth from the %changelog and we do that
> > as something useful to do for every release - then we'll be able to keep
> > it pruned down and we'll still keep the history.
> >
> > People on the packaging committe - does that sound fair?
> >
> > -sv
>
> I'm always worried about making it harder to get the history related to
> the running code... (I guess there's still always cvs history, but...)
>
> I'd like to see all changelog entries remain that are related to patches
> still carried in the src.rpm - and not thrown away just because that
> patch was added > 1 year ago. Much harder to automate, though... If
> there's a policy that says I can trim my own changelogs with that
> criteria, I'll gladly do it. (Maybe the automated trimmer could only
> nuke old changelog entries if the changelog is above a certain size
> threshold?)
So my first question is this: Why are we carrying a patch for >1yr?
Shouldn't it be being pushed to upstream?
There are many reasons for doing so, e.g.
* dead/non-responsive upstream
* upstream has adopted patch, but hasn't released a new tarball, since.
* patches lack generality/are RH/Fedora-specific hacks.
* patches contain experimental features.
...
Ralf
5:41 a.m.
On Thu, 30 Aug 2007, Eric Sandeen wrote:
I'd like to see all changelog entries remain that are related to
patches
still carried in the src.rpm - and not thrown away just because that
patch was added > 1 year ago. Much harder to automate, though... If
there's a policy that says I can trim my own changelogs with that
criteria, I'll gladly do it. (Maybe the automated trimmer could only
nuke old changelog entries if the changelog is above a certain size
threshold?)
+1 -- please keep complete %changelog in the spec file itself.
Greetings,
Robert
1:01 a.m.
On Thu, 2007-08-30 at 22:47 -0400, seth vidal wrote::
1. trim the changelogs at createrepo-runtime - fine - but that only gets
it for the repodata
2. trim repos at rpmbuild time - great - I've suggested it as an option
to rpmbuild on rpm-maint list.
3. trim them out of the pkgs the next time we change a package. Just
prune them down to the last years worth of changelogs - maybe saving the
old changelogs in a file in the cvs repository - or even into an unused
source file in the srpm?
What're people's thoughts on this?
3 is a data loss of possibly useful info, and 1 doesn't help rpm
download size. I think clearly proposal nr 2 is the best.
1:14 a.m.
On Fri, 2007-08-31 at 08:01 +0200, Alexander Larsson wrote:
On Thu, 2007-08-30 at 22:47 -0400, seth vidal wrote::
>
> 1. trim the changelogs at createrepo-runtime - fine - but that only gets
> it for the repodata
>
> 2. trim repos at rpmbuild time - great - I've suggested it as an option
> to rpmbuild on rpm-maint list.
>
> 3. trim them out of the pkgs the next time we change a package. Just
> prune them down to the last years worth of changelogs - maybe saving the
> old changelogs in a file in the cvs repository - or even into an unused
> source file in the srpm?
>
> What're people's thoughts on this?
3 is a data loss of possibly useful info, and 1 doesn't help rpm
download size. I think clearly proposal nr 2 is the best.
okay - then if 2 is implemented in rpm then I'd suggest we limit it to
the last year, that's two releases-worth of changelogs -it should cover
reasonably well.
-sv
1:30 a.m.
On Fri, 2007-08-31 at 02:14 -0400, seth vidal wrote:
On Fri, 2007-08-31 at 08:01 +0200, Alexander Larsson wrote:
> On Thu, 2007-08-30 at 22:47 -0400, seth vidal wrote::
> >
> > 1. trim the changelogs at createrepo-runtime - fine - but that only gets
> > it for the repodata
> >
> > 2. trim repos at rpmbuild time - great - I've suggested it as an option
> > to rpmbuild on rpm-maint list.
> >
> > 3. trim them out of the pkgs the next time we change a package. Just
> > prune them down to the last years worth of changelogs - maybe saving the
> > old changelogs in a file in the cvs repository - or even into an unused
> > source file in the srpm?
> >
> > What're people's thoughts on this?
>
> 3 is a data loss of possibly useful info, and 1 doesn't help rpm
> download size. I think clearly proposal nr 2 is the best.
okay - then if 2 is implemented in rpm then I'd suggest we limit it to
the last year, that's two releases-worth of changelogs -it should cover
reasonably well.
Hmm, I am not convinced that this is a good move, because such a
"time-based pruning" is a pretty random/arbitrary criterion, which is
not necessarily related to a changelog entry's value.
The same applies to "n-th last entries" or "size-based pruning".
Instead I'd prefer "source-level downsizing", i.e. maintainers to keep
their changelog's in "reasonable shape".
Ralf
1:32 a.m.
On Fri, 2007-08-31 at 08:30 +0200, Ralf Corsepius wrote:
On Fri, 2007-08-31 at 02:14 -0400, seth vidal wrote:
> On Fri, 2007-08-31 at 08:01 +0200, Alexander Larsson wrote:
> > On Thu, 2007-08-30 at 22:47 -0400, seth vidal wrote::
> > >
> > > 1. trim the changelogs at createrepo-runtime - fine - but that only gets
> > > it for the repodata
> > >
> > > 2. trim repos at rpmbuild time - great - I've suggested it as an
option
> > > to rpmbuild on rpm-maint list.
> > >
> > > 3. trim them out of the pkgs the next time we change a package. Just
> > > prune them down to the last years worth of changelogs - maybe saving the
> > > old changelogs in a file in the cvs repository - or even into an unused
> > > source file in the srpm?
> > >
> > > What're people's thoughts on this?
> >
> > 3 is a data loss of possibly useful info, and 1 doesn't help rpm
> > download size. I think clearly proposal nr 2 is the best.
>
> okay - then if 2 is implemented in rpm then I'd suggest we limit it to
> the last year, that's two releases-worth of changelogs -it should cover
> reasonably well.
Hmm, I am not convinced that this is a good move, because such a
"time-based pruning" is a pretty random/arbitrary criterion, which is
not necessarily related to a changelog entry's value.
The same applies to "n-th last entries" or "size-based pruning".
Instead I'd prefer "source-level downsizing", i.e. maintainers to keep
their changelog's in "reasonable shape".
the time based pruning would only be in the produced rpms - not in the
actual spec file. And if we have a package which is gone a year w/o
being touched in anyway that touches the changelog - maybe that's a
problem :)
-sv
1:48 a.m.
On Fri, 2007-08-31 at 02:32 -0400, seth vidal wrote:
the time based pruning would only be in the produced rpms - not in
the
actual spec file. And if we have a package which is gone a year w/o
being touched in anyway that touches the changelog - maybe that's a
problem :)
Well, for very rarely changing packages we might want cut after a year,
but keep at least 5 entries or something.
1:52 a.m.
On Fri, 31 Aug 2007, seth vidal wrote:
On Fri, 2007-08-31 at 08:30 +0200, Ralf Corsepius wrote:
> On Fri, 2007-08-31 at 02:14 -0400, seth vidal wrote:
>> On Fri, 2007-08-31 at 08:01 +0200, Alexander Larsson wrote:
>>> On Thu, 2007-08-30 at 22:47 -0400, seth vidal wrote::
>>>>
>>>> 1. trim the changelogs at createrepo-runtime - fine - but that only gets
>>>> it for the repodata
>>>>
>>>> 2. trim repos at rpmbuild time - great - I've suggested it as an
option
>>>> to rpmbuild on rpm-maint list.
>>>>
>>>> 3. trim them out of the pkgs the next time we change a package. Just
>>>> prune them down to the last years worth of changelogs - maybe saving the
>>>> old changelogs in a file in the cvs repository - or even into an unused
>>>> source file in the srpm?
>>>>
>>>> What're people's thoughts on this?
>>>
>>> 3 is a data loss of possibly useful info, and 1 doesn't help rpm
>>> download size. I think clearly proposal nr 2 is the best.
>>
>> okay - then if 2 is implemented in rpm then I'd suggest we limit it to
>> the last year, that's two releases-worth of changelogs -it should cover
>> reasonably well.
> Hmm, I am not convinced that this is a good move, because such a
> "time-based pruning" is a pretty random/arbitrary criterion, which is
> not necessarily related to a changelog entry's value.
>
> The same applies to "n-th last entries" or "size-based pruning".
>
> Instead I'd prefer "source-level downsizing", i.e. maintainers to keep
> their changelog's in "reasonable shape".
>
the time based pruning would only be in the produced rpms - not in the
actual spec file. And if we have a package which is gone a year w/o
being touched in anyway that touches the changelog - maybe that's a
problem :)
What buggers me most about this whole discussion is that we're treating a
symptom, not the disease. Adding an option to rpmbuild to cut the
changelogs where desired is no big deal, but the real issue IMO is that
there's an enormous amount of redundancy in the changelog data. All of it
is carried as a separate copy in
- each binary rpm and it's possible subpackages
- likewise for rpmdb itself for installed packages
- src.rpm header
- in the spec inside src.rpm
- repository metadata (several times due to subpackages and src.rpms)
That's helluva lot of duplicate data when you're transferring it over the
wire...
- Panu -
2:02 a.m.
On Fri, 2007-08-31 at 09:52 +0300, Panu Matilainen wrote:
What buggers me most about this whole discussion is that we're
treating a
symptom, not the disease. Adding an option to rpmbuild to cut the
changelogs where desired is no big deal, but the real issue IMO is that
there's an enormous amount of redundancy in the changelog data. All of it
is carried as a separate copy in
- each binary rpm and it's possible subpackages
- likewise for rpmdb itself for installed packages
- src.rpm header
- in the spec inside src.rpm
- repository metadata (several times due to subpackages and src.rpms)
That's helluva lot of duplicate data when you're transferring it over the
wire...
Yes,
but the above solution (whenever that might happen) doesn't solve
carrying 10+ years of changelogs around. It's still more data than we
probably need in any one or N locations.
-sv
9:46 a.m.
On Fri, 31 Aug 2007 09:52:28 +0300 (EEST)
Panu Matilainen <pmatilai(a)laiskiainen.org> wrote:
On Fri, 31 Aug 2007, seth vidal wrote:
> On Fri, 2007-08-31 at 08:30 +0200, Ralf Corsepius wrote:
>> On Fri, 2007-08-31 at 02:14 -0400, seth vidal wrote:
>>> On Fri, 2007-08-31 at 08:01 +0200, Alexander Larsson wrote:
>>>> On Thu, 2007-08-30 at 22:47 -0400, seth vidal wrote::
>>>>>
>>>>> 1. trim the changelogs at createrepo-runtime - fine - but that only
gets
>>>>> it for the repodata
>>>>>
>>>>> 2. trim repos at rpmbuild time - great - I've suggested it as an
option
>>>>> to rpmbuild on rpm-maint list.
>>>>>
>>>>> 3. trim them out of the pkgs the next time we change a package.
Just
>>>>> prune them down to the last years worth of changelogs - maybe saving
the
>>>>> old changelogs in a file in the cvs repository - or even into an
unused
>>>>> source file in the srpm?
>>>>>
>>>>> What're people's thoughts on this?
>>>>
>>>> 3 is a data loss of possibly useful info, and 1 doesn't help rpm
>>>> download size. I think clearly proposal nr 2 is the best.
>>>
>>> okay - then if 2 is implemented in rpm then I'd suggest we limit it to
>>> the last year, that's two releases-worth of changelogs -it should cover
>>> reasonably well.
>> Hmm, I am not convinced that this is a good move, because such a
>> "time-based pruning" is a pretty random/arbitrary criterion, which is
>> not necessarily related to a changelog entry's value.
>>
>> The same applies to "n-th last entries" or "size-based
pruning".
>>
>> Instead I'd prefer "source-level downsizing", i.e. maintainers to
keep
>> their changelog's in "reasonable shape".
>>
>
> the time based pruning would only be in the produced rpms - not in the
> actual spec file. And if we have a package which is gone a year w/o
> being touched in anyway that touches the changelog - maybe that's a
> problem :)
What buggers me most about this whole discussion is that we're treating a
symptom, not the disease. Adding an option to rpmbuild to cut the
Thank you. I was waiting for someone to mention that. Treating the symptom is not the
right answer.
changelogs where desired is no big deal, but the real issue IMO is
that
there's an enormous amount of redundancy in the changelog data. All of it
is carried as a separate copy in
- each binary rpm and it's possible subpackages
- likewise for rpmdb itself for installed packages
- src.rpm header
- in the spec inside src.rpm
- repository metadata (several times due to subpackages and src.rpms)
That's helluva lot of duplicate data when you're transferring it over the
wire...
Everyone likes to talk about use cases, so let's go down that road. What are the use
cases for the RPM changelog data?
1) Like many people have said, I like to 'rpm -q --changelog' an RPM to see what
has changed. Especially if its functionality has changed from what I know. Maybe
it's desired or undesired, but the changelog gives a quick indication.
2) People like to query the changelog in the RPM to look for specific bug numbers.
What else?
We can still deliver that to the target system. Panu has already pointed out that we
already deliver the changelog at least 5 times over. We should figure out where to put
this information once and still be able to deliver it to the target system.
Arbitrarily deciding to remove all changelog entries older than 1 year is stupid. For
some packages you'll end up with one entry (or none!) and for some packages you
probably won't make a dent (kernel?).
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat / Westford, MA
10:09 a.m.
David Cantrell wrote:
Arbitrarily deciding to remove all changelog entries older than 1
year is stupid. For some packages you'll end up with one entry (or none!) and for
some packages you probably won't make a dent (kernel?).
It seems reasonable to me, as a simple starting point, to ask
maintainers to trim changelogs to information that is relevant to that
%{VERSION}. (maybe last 2 versions). Ideally that changelog would
contain documentation for all patches still carried, and go back to the
changelog entry that bumped the version (or 2). Perhaps if that version
bump caused patches to be removed, that should also be in the changelog,
with rationale ("patch FOO removed, now upstream").
If the changelog entries have the format:
* <date> <author> <version>
then presumably automated checks could be run for changelog entries
older than the current revision (or 2), and warnings or errors issued.
If you must know what happened before that, go get the older rpm and
take a peek.
I know this doesn't address the replicated data issue, but it might
address the size of the data being replicated, at least :)
-Eric
1:44 p.m.
On Fri, 31 Aug 2007 10:09:09 -0500
Eric Sandeen <sandeen(a)redhat.com> wrote:
David Cantrell wrote:
> Arbitrarily deciding to remove all changelog entries older than 1 year is stupid.
For some packages you'll end up with one entry (or none!) and for some packages you
probably won't make a dent (kernel?).
It seems reasonable to me, as a simple starting point, to ask
maintainers to trim changelogs to information that is relevant to that
%{VERSION}. (maybe last 2 versions). Ideally that changelog would
contain documentation for all patches still carried, and go back to the
changelog entry that bumped the version (or 2). Perhaps if that version
bump caused patches to be removed, that should also be in the changelog,
with rationale ("patch FOO removed, now upstream").
I think this is fine as a distribution policy that package maintainers should follow, sort
of a best practices approach.
If the changelog entries have the format:
* <date> <author> <version>
then presumably automated checks could be run for changelog entries
older than the current revision (or 2), and warnings or errors issued.
If you must know what happened before that, go get the older rpm and
take a peek.
I don't think an automated script to prune changelogs is necessary or even a good
idea. Package maintainers should be told what best practices to follow and that's it.
We shouldn't be relying on so many housekeeping scripts that may or may not work.
Packages vary greatly, especially the changelog data. Some packages are essentially the
upstream source for a project, so that changelog may be way more verbose than something we
just compile and pack up.
I think it's a task for the package maintainer and not a script.
I know this doesn't address the replicated data issue, but it
might
address the size of the data being replicated, at least :)
But it's sort of pointless to go to the trouble to remove a relatively minor amount of
text to gain a small amount of space. I think time is better spent solving the actual
problem.
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat / Westford, MA
1:58 p.m.
On 8/31/07, David Cantrell <dcantrell(a)redhat.com> wrote:
Some packages are essentially the upstream source for a project,
Yes, and I think this should be strongly discouraged. For starters, spec
files and patches are a poor substitute for revision control. It also makes
it significantly more painful for other people to reuse the work (c.f. the
Ubuntu developer's request).
If we have situations like this - put up a project on
hosted.fedoraproject.org. Or code.google.com. Or sourceforge.
2 p.m.
On Fri, 31 Aug 2007 14:58:26 -0400
"Colin Walters" <walters(a)redhat.com> wrote:
On 8/31/07, David Cantrell <dcantrell(a)redhat.com> wrote:
>
>
> Some packages are essentially the upstream source for a project,
Yes, and I think this should be strongly discouraged. For starters, spec
files and patches are a poor substitute for revision control. It also makes
it significantly more painful for other people to reuse the work (c.f. the
Ubuntu developer's request).
If we have situations like this - put up a project on
hosted.fedoraproject.org. Or code.google.com. Or sourceforge.
Done and done. I moved mine, but some haven't moved and probably won't for a
while. Even when they do move, the project will need to change how it handles recording
changes going forward.
I'm just saying that having a script mow down changelog entries is a bad idea. It
should be in the hands of the package maintainer.
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat / Westford, MA
2:16 p.m.
On Fri, 2007-08-31 at 15:00 -0400, David Cantrell wrote:
On Fri, 31 Aug 2007 14:58:26 -0400
"Colin Walters" <walters(a)redhat.com> wrote:
> On 8/31/07, David Cantrell <dcantrell(a)redhat.com> wrote:
> >
> >
> > Some packages are essentially the upstream source for a project,
>
>
> Yes, and I think this should be strongly discouraged. For starters, spec
> files and patches are a poor substitute for revision control. It also makes
> it significantly more painful for other people to reuse the work (c.f. the
> Ubuntu developer's request).
>
> If we have situations like this - put up a project on
> hosted.fedoraproject.org. Or code.google.com. Or sourceforge.
Done and done. I moved mine, but some haven't moved and probably won't for a
while. Even when they do move, the project will need to change how it handles recording
changes going forward.
I'm just saying that having a script mow down changelog entries is a bad idea. It
should be in the hands of the package maintainer.
I'm sorry if I said this incorrectly. we wouldn't be removing them from
the spec files. It would only be not including them in the binary rpms
that get created.
nothing would get edited out of someone's specfile automatically.
-sv
2:15 p.m.
On Fri, 2007-08-31 at 14:58 -0400, Colin Walters wrote:
On 8/31/07, David Cantrell <dcantrell(a)redhat.com> wrote:
Some packages are essentially the upstream source for a
project,
Yes, and I think this should be strongly discouraged. For starters,
spec files and patches are a poor substitute for revision control. It
also makes it significantly more painful for other people to reuse the
work ( c.f. the Ubuntu developer's request).
If we have situations like this - put up a project on
hosted.fedoraproject.org. Or code.google.com. Or sourceforge.
+1 to hosted.fedoraproject.org
-sv
9:26 p.m.
Eric Sandeen <sandeen(a)redhat.com> wrote:
David Cantrell wrote:
> Arbitrarily deciding to remove all changelog entries older than 1
> year is stupid. For some packages you'll end up with one entry (or
> none!) and for some packages you probably won't make a dent
> (kernel?).
;-)
It seems reasonable to me, as a simple starting point, to ask
maintainers to trim changelogs to information that is relevant to that
%{VERSION}. (maybe last 2 versions). Ideally that changelog would
contain documentation for all patches still carried, and go back to the
changelog entry that bumped the version (or 2). Perhaps if that version
bump caused patches to be removed, that should also be in the changelog,
with rationale ("patch FOO removed, now upstream").
Problem is that I've got changelog entries like:
- Update to new version
- Carry patch NN forward
- Fix SPEC for guidelines
- New/changed configuration file XYZ
- ...
You can't just keep it all or none, and editing out "now uninteresting
bits" and keeping all elsewhere makes the exercise rather pointless IMHO.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
1:46 a.m.
On Fri, 2007-08-31 at 08:30 +0200, Ralf Corsepius wrote:
On Fri, 2007-08-31 at 02:14 -0400, seth vidal wrote:
> On Fri, 2007-08-31 at 08:01 +0200, Alexander Larsson wrote:
> > On Thu, 2007-08-30 at 22:47 -0400, seth vidal wrote::
> > >
> > > 1. trim the changelogs at createrepo-runtime - fine - but that only gets
> > > it for the repodata
> > >
> > > 2. trim repos at rpmbuild time - great - I've suggested it as an
option
> > > to rpmbuild on rpm-maint list.
> > >
> > > 3. trim them out of the pkgs the next time we change a package. Just
> > > prune them down to the last years worth of changelogs - maybe saving the
> > > old changelogs in a file in the cvs repository - or even into an unused
> > > source file in the srpm?
> > >
> > > What're people's thoughts on this?
> >
> > 3 is a data loss of possibly useful info, and 1 doesn't help rpm
> > download size. I think clearly proposal nr 2 is the best.
>
> okay - then if 2 is implemented in rpm then I'd suggest we limit it to
> the last year, that's two releases-worth of changelogs -it should cover
> reasonably well.
Hmm, I am not convinced that this is a good move, because such a
"time-based pruning" is a pretty random/arbitrary criterion, which is
not necessarily related to a changelog entry's value.
The same applies to "n-th last entries" or "size-based pruning".
But all the information is still there if you really want it, in:
a) The specfile in the srpm
b) in cvs
2:08 a.m.
On Fri, 2007-08-31 at 08:46 +0200, Alexander Larsson wrote:
On Fri, 2007-08-31 at 08:30 +0200, Ralf Corsepius wrote:
> On Fri, 2007-08-31 at 02:14 -0400, seth vidal wrote:
> > On Fri, 2007-08-31 at 08:01 +0200, Alexander Larsson wrote:
> > > On Thu, 2007-08-30 at 22:47 -0400, seth vidal wrote::
> > > >
> > > > 1. trim the changelogs at createrepo-runtime - fine - but that only
gets
> > > > it for the repodata
> > > >
> > > > 2. trim repos at rpmbuild time - great - I've suggested it as an
option
> > > > to rpmbuild on rpm-maint list.
> > > >
> > > > 3. trim them out of the pkgs the next time we change a package. Just
> > > > prune them down to the last years worth of changelogs - maybe saving
the
> > > > old changelogs in a file in the cvs repository - or even into an
unused
> > > > source file in the srpm?
> > > >
> > > > What're people's thoughts on this?
> > >
> > > 3 is a data loss of possibly useful info, and 1 doesn't help rpm
> > > download size. I think clearly proposal nr 2 is the best.
> >
> > okay - then if 2 is implemented in rpm then I'd suggest we limit it to
> > the last year, that's two releases-worth of changelogs -it should cover
> > reasonably well.
> Hmm, I am not convinced that this is a good move, because such a
> "time-based pruning" is a pretty random/arbitrary criterion, which is
> not necessarily related to a changelog entry's value.
>
> The same applies to "n-th last entries" or "size-based
pruning".
But all the information is still there if you really want it, in:
a) The specfile in the srpm
b) in cvs
Right, but that's not the issue - The issue is: What are the
changelog
entries inside of binary rpms being used for.
I see several aspects:
- Users wanting to retrieve some abstract about recent changes, for
whatever reasons (I presume mostly bureaucratic ones, such like
maintainers being able to send their users/bosses update notices)
- Users wanting to check a binary rpm for "if bug XYZ" has been
fixed/addressed.
- Legal people/developers wanting to check a binary rpm for
"relationship" to other "binary packages" (Q's such as "Has
RH adopted
the suse-spec. Was RH first to integrate this "patent violation patch",
"Has Fedora removed this "patent violation")
- Developers wanting to check for "when was that package upgraded to
version XYZ".
...
Any such "simple pruning" will somehow interfere with any such attempts.
Ralf
4:37 a.m.
Le Ven 31 août 2007 08:46, Alexander Larsson a écrit :
But all the information is still there if you really want it, in:
a) The specfile in the srpm
b) in cvs
Both useless for the poor guy on a corporate internet-less lan that
tries to figure why and update broke his system.
+1 for making changelog storage more efficient (is the data compressed
at all?
+1 for trimming changelog
-10 for removing local changelog storage "because it's in some on-line
packager infrastructure"
--
Nicolas Mailhot
3:03 a.m.
seth vidal wrote:
1. trim the changelogs at createrepo-runtime - fine - but that only gets
it for the repodata
2. trim repos at rpmbuild time - great - I've suggested it as an option
to rpmbuild on rpm-maint list.
3. trim them out of the pkgs the next time we change a package. Just
prune them down to the last years worth of changelogs - maybe saving the
old changelogs in a file in the cvs repository - or even into an unused
source file in the srpm?
Option #2 seems best to me. The size of the sources is less critical
than the size of the binary RPMS. Meanwhile it might be more convenient
to have an unbroken history all in one place, instead of a place on the
side to check.
Warren Togami
wtogami(a)redhat.com
3:57 a.m.
On Thu, 2007-08-30 at 22:47 -0400, seth vidal wrote:
1. trim the changelogs at createrepo-runtime - fine - but that only
gets
it for the repodata
2. trim repos at rpmbuild time - great - I've suggested it as an option
to rpmbuild on rpm-maint list.
What're people's thoughts on this?
I guess ideally as a "changelog" that it would magically get clipped to
the changes from this release to the last release. Don't see how to
actually do that though, except by fiddling our build infrastructure to
suck the last fedora release nvr from koji and use that as the lowest
entry in the changelog to retain at buildbot rpmbuild time.
C.
4:47 a.m.
seth vidal wrote :
1. trim the changelogs at createrepo-runtime - fine - but that only
gets
it for the repodata
2. trim repos at rpmbuild time - great - I've suggested it as an option
to rpmbuild on rpm-maint list.
3. trim them out of the pkgs the next time we change a package. Just
prune them down to the last years worth of changelogs - maybe saving the
old changelogs in a file in the cvs repository - or even into an unused
source file in the srpm?
I also like the 2nd option best. Seems like the best balance between
space saved and relevant information kept easily available.
And for older information we still have the original spec file.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 7 (Moonshine) - Linux kernel 2.6.22.5-71.fc7
Load : 0.44 0.71 0.63
5:15 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matthias Saou wrote:
seth vidal wrote :
> 2. trim repos at rpmbuild time - great - I've suggested it as an option
> to rpmbuild on rpm-maint list.
>
I also like the 2nd option best. Seems like the best balance between
space saved and relevant information kept easily available.
And for older information we still have the original spec file.
Matthias
Does this concern the .spec %changelog only, or does this also include
any ChangeLog/CHANGES file in the actual source when pulled into the
(binary) RPM?
Would the SRPM still have the full changelog/spec?
- --
Kind regards,
Jeroen van Meeuwen
- -kanarip
- --
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258 F70B 28DE 9FDA 9342 BF08
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFG1+mXKN6f2pNCvwgRArspAJ4hfxTzJ9w3EKLtL8Qw4qkfOB9+vQCgnR3B
wMFzr6cj4NnDxmzMGwjEwK0=
=FVSb
-----END PGP SIGNATURE-----
9:21 a.m.
Matthias Saou wrote:
seth vidal wrote :
> 1. trim the changelogs at createrepo-runtime - fine - but that only gets
> it for the repodata
>
> 2. trim repos at rpmbuild time - great - I've suggested it as an option
> to rpmbuild on rpm-maint list.
>
> 3. trim them out of the pkgs the next time we change a package. Just
> prune them down to the last years worth of changelogs - maybe saving the
> old changelogs in a file in the cvs repository - or even into an unused
> source file in the srpm?
I also like the 2nd option best. Seems like the best balance between
space saved and relevant information kept easily available.
And for older information we still have the original spec file.
Matthias
Perhaps the end of the auto-trimmed %changelog could have text inserted
that points at a URL to the full %changelog.
Warren Togami
wtogami(a)redhat.com
8:46 a.m.
On 8/31/07, seth vidal <skvidal(a)fedoraproject.org> wrote:
Colin Walters mentioned on irc reducing the changelogs kept in pkgs
a
bit to help us fit on the livecd a bit better. I didn't really believe
it would make enough of an impact to be noticeable but I did a little
mucking about and found I was wrong. So I wrote this:
http://skvidal.fedorapeople.org/changelog/changelog-sizes.py
It'll dump out 4 files:
- old-repo.txt : changelogs from the pkgs in the repos where the
changelog entry is > 1yr old
- new-repo.txt : changelogs from the pkgs in the repos where the
changelog entry is < 1yr old
- old-db.txt : changelogs from the pkgs in the rpmdb where the changelog
entry is > 1yr old
- new-db.txt : changelogs from the pkgs in the rpmdb where the changelog
entry is < 1yr old
On a mostly-rawhide system with rawhide repos I found:
8157 pkgs in rawhide repos:
new changelogs: 12M
old changelogs: 31M
on my system 1128 packages installed:
new changelogs: 2.2M
old changelogs: 8.6M
That may not seem like much but when we're squinched for space in 700M
on a livecd that 8.6M might be all that's needed. Moreover it may be a
bit silly to be carting all of this history around in all the pkgs and
repodata and in the rpmdb. Esp if we're trying to trim download sizes
for various items. So things we can do:
1. trim the changelogs at createrepo-runtime - fine - but that only gets
it for the repodata
2. trim repos at rpmbuild time - great - I've suggested it as an option
to rpmbuild on rpm-maint list.
3. trim them out of the pkgs the next time we change a package. Just
prune them down to the last years worth of changelogs - maybe saving the
old changelogs in a file in the cvs repository - or even into an unused
source file in the srpm?
What're people's thoughts on this?
If the changelog is trimmed, it would be nice if the full changelog
was provided in a new gzip compressed field. New versions of rpm would
read and see the full changelog, while old versions would just get the
trimmed version. On my system 8MB of changelogs generated by the
script compresses to 2MB.
Honestly though, I think there are probably better places to look for
space savings.
n0dalus.
9:33 a.m.
seth vidal wrote:
8157 pkgs in rawhide repos:
new changelogs: 12M
old changelogs: 31M
on my system 1128 packages installed:
new changelogs: 2.2M
old changelogs: 8.6M
That may not seem like much but when we're squinched for space in 700M
on a livecd that 8.6M might be all that's needed. Moreover it may be a
bit silly to be carting all of this history around in all the pkgs and
repodata and in the rpmdb. Esp if we're trying to trim download sizes
for various items. So things we can do:
At first I think starting this discussion with the live CD in mind is a
mistake. If 700MB is not sufficient use an DVD - or replace GNOME/KDE by
FVWM. Saving a few megs won't cut it anyway. Crippling RPM/our packages just
to create a LiveCD sounds like a bad idea. Especially as the Fedora (as a
usable installation) grows from release to release and won't fit into the
won space quite soon.
Nevertheless we are moving a lot of of unnecessary data over the wire. The
way to go in the long run would be to compress the rpm headers. This would
not only reduce the bandwidth wasted for the changelog but also for all the
other tags - the file list to name the biggest one. Panu to the rescue!
Florian
10:23 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
seth vidal wrote:
1. trim the changelogs at createrepo-runtime - fine - but that only
gets
it for the repodata
2. trim repos at rpmbuild time - great - I've suggested it as an option
to rpmbuild on rpm-maint list.
3. trim them out of the pkgs the next time we change a package. Just
prune them down to the last years worth of changelogs - maybe saving the
old changelogs in a file in the cvs repository - or even into an unused
source file in the srpm?
What're people's thoughts on this?
I dislike all of these options for different reasons. I would like the
following features in a solution:
1) Automated -- having individual maintainers do it takes up their time
and leads to different treatment of changelogs depending on the maintainer.
2) Consistent -- Ideally, all changelog entries from the newest to the
oldest would get the same treatment.
3) Happens as early in rpm creation as possible -- If it occurs at
createrepo time it only deals with one level of the problem. Happening
at rpmbuild time handles repodata, rpm header, and rpmdb. Spec file
time includes the spec and srpm.
A) Bonus feature: tie the cvs and changelog information together -- This
is a separate issue as the cvs changelog goes through an entirely
different set of distribution channels as the rpm changelog. But it is
a needless duplication.
So far, I like Florian Festi's idea to compress all the rpm headers the
most as it addresses 1, 2, and 3 above but I haven't found anything that
tells what Panu's thoughts on this are.
- -Toshio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFG2DJrX6yAic2E7kgRAu+gAJ4nCI5mDaoizDVj96ZPCm6Qz747gwCgiKjO
Y4WZQGjmM9gzLAYvswuqF6M=
=70qw
-----END PGP SIGNATURE-----
10:45 a.m.
On 8/31/07, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
A) Bonus feature: tie the cvs and changelog information together -- This
is a separate issue as the cvs changelog goes through an entirely
different set of distribution channels as the rpm changelog. But it is
a needless duplication.
This one was actually a bigger concern - mostly the developer time wasted in
maintaining it versus just using "cvs commit". (I know "make clog"
exists as
a workaround). Anyways I installed TurboGears last weekend and started on a
fix, we'll see if I can make it go.
3:25 p.m.
seth vidal (skvidal(a)fedoraproject.org) said:
on my system 1128 packages installed:
new changelogs: 2.2M
old changelogs: 8.6M
That may not seem like much but when we're squinched for space in 700M
on a livecd that 8.6M might be all that's needed.
I'm not sure. Trying to fit on a livecd is always a losing game - software
never gets smaller, the media never gets bigger; all this will save us
is maybe one release cycle of pain.
It's not to say we can't try and not have the data in so many places,
but I don't think livecd should be the deciding reason.
Bill
3:30 p.m.
On Fri, 2007-08-31 at 16:25 -0400, Bill Nottingham wrote:
seth vidal (skvidal(a)fedoraproject.org) said:
> on my system 1128 packages installed:
> new changelogs: 2.2M
> old changelogs: 8.6M
>
>
> That may not seem like much but when we're squinched for space in 700M
> on a livecd that 8.6M might be all that's needed.
I'm not sure. Trying to fit on a livecd is always a losing game - software
never gets smaller, the media never gets bigger; all this will save us
is maybe one release cycle of pain.
It's not to say we can't try and not have the data in so many places,
but I don't think livecd should be the deciding reason.
Fair enough - but 30M is a lot of space for things like olpc and/or
usb-key-running-images.
-sv
4:39 p.m.
Bill Nottingham wrote:
seth vidal (skvidal(a)fedoraproject.org) said:
> on my system 1128 packages installed:
> new changelogs: 2.2M
> old changelogs: 8.6M
>
>
> That may not seem like much but when we're squinched for space in 700M
> on a livecd that 8.6M might be all that's needed.
I'm not sure. Trying to fit on a livecd is always a losing game - software
never gets smaller, the media never gets bigger; all this will save us
is maybe one release cycle of pain.
OTOH that is the great thing about the game. It puts a very clear
pressure in place to prevent, or at least slow, bloat.
I'm personally AMAZED that fedora7 runs what I would call "usably well"
on a 7? year old laptop I have that has <128M ram (some shared with
video). My speculation was that the only reason this happened, was
because of the pressure OLPC put on the distro.
Looking forward, don't we want fedora to be usable as an embedded
distro? That was a laughable proposition before OLPC, but with 8G
microsd flash shipping, and no doubt being 'dirt' cheap in a couple years...
So maybe the above (I'm skeptical, was that 8.6M *squashfs compressed*
saved?) only helps for one release cycle. Then for a release cycle or
two you have to sacrifice shipping every language in the world on the
same cd, and go with regional spins. I can see the 700M form factor
lasting quite a while. And I think that the pain of trying to make it
last, will have many, perhaps more important, secondary benefits.
$0.02...
-dmc
10:52 p.m.
Douglas McClendon (dmc.fedora(a)filteredperception.org) said:
So maybe the above (I'm skeptical, was that 8.6M *squashfs
compressed*
saved?) only helps for one release cycle. Then for a release cycle or two
you have to sacrifice shipping every language in the world on the same cd,
and go with regional spins.
That's my point, though - how is a release method where each release
you offer *less* functionality to the user a good thing?
Bill
11:30 p.m.
Bill Nottingham <notting(a)redhat.com> writes:
That's my point, though - how is a release method where each
release
you offer *less* functionality to the user a good thing?
Are we offering *less* functionality, or *different* functionality?
There's certainly a zero-sum game involved when you're discussing
what you can put on a given-size CD.
I'm +1 for dropping blow-by-blow changelogs out of that limited
footprint --- the people who care about those details probably care
about access to the source code too, and I don't see anyone insisting
that we ship full source on livecd.
I'm also +1 for the discipline of packing as much functionality as
possible onto limited space. But detailed changelogs seem to me
to not qualify as critical functionality.
regards, tom lane
11:41 p.m.
On Fri, 2007-08-31 at 23:52 -0400, Bill Nottingham wrote:
Douglas McClendon (dmc.fedora(a)filteredperception.org) said:
> So maybe the above (I'm skeptical, was that 8.6M *squashfs compressed*
> saved?) only helps for one release cycle. Then for a release cycle or two
> you have to sacrifice shipping every language in the world on the same cd,
> and go with regional spins.
That's my point, though - how is a release method where each release
you offer *less* functionality to the user a good thing?
Of cause not, but ...
All this is based on the assumption "media technology doesn't evolve".
Fact is it does.
We once had "Linux on 5 floppies", then "Linux on CD", then
"Linux on X
CDs", then "Linux on DVD", now we're gradually approaching the
"Linux on
online media-age".
That said, I don't see much sense in spinning "crippled distros on
<small media>". Instead we should have a very small "minimum
installation/loader <medium>", which should redirect users either to
further "add-on <media>" or directly send them on-line.
In an ideal world, I would like to see something like a set of CDs/DVDs,
one of which is "the installer CD", and a loosely coupled set of CDs
containing all packages Fedora consists of. Not a "Gnome-edition", not a
"KDE-edition", not a "gamers', engineer's or whatever
edition".
Actually, I thought that this would be what you (rel-eng) guys would be
working on.
Ralf
3:12 a.m.
On Saturday 01 September 2007 06:41:27 Ralf Corsepius wrote:
We once had "Linux on 5 floppies", then "Linux on
CD", then "Linux on X
CDs", then "Linux on DVD", now we're gradually approaching the
"Linux on
online media-age".
That said, I don't see much sense in spinning "crippled distros on
<small media>". Instead we should have a very small "minimum
I guess this is true for Western Europe and other developed countries, but
Fedora targets for a world-wide domination and e.g. in development or newly
industrialising countries, there may not be cheap access to even DVDs or usb
devices of a useful capacity.
Regards,
Till
2:43 p.m.
Bill Nottingham wrote:
Douglas McClendon (dmc.fedora(a)filteredperception.org) said:
> So maybe the above (I'm skeptical, was that 8.6M *squashfs compressed*
> saved?) only helps for one release cycle. Then for a release cycle or two
> you have to sacrifice shipping every language in the world on the same cd,
> and go with regional spins.
That's my point, though - how is a release method where each release
you offer *less* functionality to the user a good thing?
I guess the rest of my reply that you didn't quote, failed to make an
impression.
I consider it in the language of economics and utility. Pain will be
felt during the decision to remove languages or other actual
functionality. That pain will, in general, tend to cause more thought
towards other decisions that could be made, that would keep the size
down, without losing actual functionality.
In the absence of having a clear 700M bottom edge, that pain, leading to
those thoughts, will never happen, and bloat will happen unrestrained,
thus at a faster pace.
Sort of like how the 4th ammendment slows the descent into fascism.
Sure, it seems inevitable that with technological progress, the 4th
ammendment, just like the 700MB fully functional distro, will fall by
the wayside. But the longer it is there, and annoying people cling to
the value of it, the slower the actual descent into hell.
-dmc
2:09 p.m.
On Sat, 2007-09-01 at 17:17 +0200, nodata wrote:
Am Donnerstag, den 30.08.2007, 22:47 -0400 schrieb seth vidal:
> > 1yr old
What about one year older than the lifetime of the package?
On RHEL I'd like to see the changelogs for the entire life of the
platform plus that year (so that the changelogs aren't empty on a new
install).
This has nothing to do with RHEL. This is only about fedora.
-sv
2:41 p.m.
On Saturday 01 September 2007 21:09:10 seth vidal wrote:
On Sat, 2007-09-01 at 17:17 +0200, nodata wrote:
> On RHEL I'd like to see the changelogs for the entire life
of the
> platform plus that year (so that the changelogs aren't empty on a new
> install).
This has nothing to do with RHEL. This is only about fedora.
Maybe he also meant Fedora EPEL,
Regards,
Till
3:55 p.m.
On Sat, 1 Sep 2007 21:41:39 +0200, Till Maas wrote:
On Saturday 01 September 2007 21:09:10 seth vidal wrote:
> On Sat, 2007-09-01 at 17:17 +0200, nodata wrote:
> > On RHEL I'd like to see the changelogs for the entire life of the
> > platform plus that year (so that the changelogs aren't empty on a new
> > install).
>
> This has nothing to do with RHEL. This is only about fedora.
Maybe he also meant Fedora EPEL,
Doesn't matter. Basically, every package maintainer is free to drop
irrelevant changelog entries from a spec file when they become old --
unless a policy forbids that. And many packages really contain dozens
of non-interesting entries, such as
- update to 1.2.3
- rebuilt
- update to 1.2.2
- rebuilt
- rebuilt
- update to 1.2.1
- rebuilt
- sync with devel
- minor spec changes
- update to 1.2.0
...
- mass-rebuild
- rebuilt
- patch merged upstream <-- in a comment from 1999 - uh?
- update to 0.3.0
which go back several years. In 2007, nobody has any interest in
whether a package was at 0.3.0 eight years ago or whether the packager
at that time had to patch an early release every week because of lack
of code stability. It also doesn't matter whether a package started
with a different packager, because the majority of spec files are
straight-forward to write from scratch. Perhaps only if over time
somebody has created a spec file of extra-ordinary size and complexity
credits are due. But solely based on reading a spec changelog one
usually cannot see who has written exactly what lines in the file.
For the user, the interesting entries are those that comment on
- differences between the package as it was included on distribution
media and later official updates,
- all comments on patches, which are still included in the package,
and
- comments on past packaging mistakes/pitfalls, which shall be
avoided in the future (preferably these are inline comments, though).
Everything other than than and older than that is likely of very
limited value.
4:38 p.m.
New subject: Viewing changelog entries on package updates (was Re: changelogs in packages and space use)
On Sat, 2007-09-01 at 22:55 +0200, Michael Schwendt wrote:
[snip]
And many packages really contain dozens
of non-interesting entries, such as
- update to 1.2.3
- rebuilt
- update to 1.2.2
- rebuilt
- rebuilt
- update to 1.2.1
- rebuilt
- sync with devel
- minor spec changes
- update to 1.2.0
...
- mass-rebuild
- rebuilt
- patch merged upstream <-- in a comment from 1999 - uh?
- update to 0.3.0
[snip]
Reading this reminded me of something - It's really annoying to have to
download in many cases 100-200MB of packages to find that the changelog
contained 'rebuild' or some other minor change that might not affect you
at all. Many people have a cap on bandwidth so it's a shame to waste
that 200MB, not to mention that time for those on dial-up.
A configurable option in Pirut that would display the changelog entries
of a package from the currently installed version to the updated version
in the 'Update Details' window would be very useful. I'm just not sure
how hard it would be to integrate into Pirut / if the metadata contains
that information so I'll say sorry in advance if this is completely
unfeasible/unreasonable.
A workaround would be deltaRPMs in which case that 200MB becomes
something more like 10MB, but even then the changelog view is still
nice ;)
Regards,
Stewart
4:58 p.m.
New subject: Viewing changelog entries on package updates (was Re: changelogs in packages and space use)
On Sat, 01 Sep 2007 17:38:56 -0400, Stewart Adam wrote:
Reading this reminded me of something - It's really annoying to
have to
download in many cases 100-200MB of packages to find that the changelog
contained 'rebuild' or some other minor change that might not affect you
at all. Many people have a cap on bandwidth so it's a shame to waste
that 200MB, not to mention that time for those on dial-up.
It may be a _required_ rebuild, e.g. due to changes in the compiler or
libraries, and the changelog just doesn't give any details.
What should not happen is what has happened recently. Packagers
rebuilding their packages for FC-6 with just an increased release
value "to keep NVR in sync" with the mass-rebuild in devel, or package
rebuilds for the old dists for just an updated "License" field. I
agree that such rebuilds are annoying (especially when they trigger
.rpmsave/.rpmnew actions).
In general, IMHO, packagers should refrain from doing "rebuilds
without details in changelog" in stable branches of the
distribution. For devel, such rebuilds are normal (although the
packager could also explain the need for the rebuild when it is
not just a trial-and-error rebuild against the latest build env).
9:14 a.m.
New subject: Viewing changelog entries on package updates (was Re: changelogs in packages and space use)
On Sat, 2007-09-01 at 17:38 -0400, Stewart Adam wrote:
A configurable option in Pirut that would display the changelog
entries
of a package from the currently installed version to the updated version
in the 'Update Details' window would be very useful. I'm just not sure
how hard it would be to integrate into Pirut / if the metadata contains
that information so I'll say sorry in advance if this is completely
unfeasible/unreasonable.
Well, the idea is that the update notices[1] can provide this
information and that should be back RSN. Downloading the changelog data
gets kind of painful (the metadata file with changelogs is currently at
twice the size of the filelists which I consider pretty painfully large
to have to download)
Jeremy
[1] The problem is that rawhide doesn't have these. Although I have
seriously considered writing the simple stupid "snag the last n
changelogs and stuff them into the update metadata format" script that
could then be run on rawhide pushes. Even better would be if it did the
changelog diff from the previously pushed package like the rawhide mails
do. If someone wants to work on this, let me know and I can help point
you in the right direction
6081
days inactive
6085
days old
51 comments
26 participants
participants (26)
-
Alexander Larsson -
Bill Nottingham -
Caolán McNamara -
Colin Walters -
David Cantrell -
Douglas McClendon -
Eric Sandeen -
Florian Festi -
Horst H. von Brand -
Jeremy Katz -
Jeroen van Meeuwen -
Mamoru Tasaka -
Matthias Saou -
Michael Schwendt -
n0dalus -
Nicolas Mailhot -
nodata -
Panu Matilainen -
Ralf Corsepius -
Robert Scheck -
Seth Vidal -
Stewart Adam -
Till Maas -
Tom Lane -
Toshio Kuratomi -
Warren Togami