Re: changelogs in packages and space use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux