FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Packaging

 
 
LinkBack Thread Tools
 
Old 01-02-2008, 02:20 PM
Ralf Corsepius
 
Default release of subpackage with version different from main rpm

On Thu, 2008-01-03 at 00:02 +0900, Mamoru Tasaka wrote:
> Hi:
>
> I guess there are some packages of which subpackage rpms have versions
> which are different from those of the main rpm.
> For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage
> perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR.
>
> On such case are there any policy for release number?
Except that all packages' and sub-packages' NEVRs must be steadily
increasing, there are no explicit policies.


> For perl currently
> the main perl rpm and its subpackages have the same release number.
Right, ... because they are being built as part of the main-perl
package.

> However in other rpms the case may happen that only the version of
> main rpm will be bumped where the version of its subpackage won't change.
Right, this also happens for the perl-package.

Actually, ATM, the main-perl-package-sources and the sub-packages's
sources are independently released, but built simultaneously.

I.e. if wanting to be pendantic, theoretically the main-perl package and
it's sub-packages are independent.

I.e. the fact the sub-packages currently receive identical %rel-tags as
the main perl-packages is motivated from "trying to keep the perl
package's spec file simple" (and to avoid rpmbuild bugs - processing
%version/%release in *.specs is error-prone at best) and can be
considered somewhat "sloppy"/"lazy".

> In that case usually we want to switch the release number of main rpm
> to 1%{?dist}, however if its subpackage has different version the release
> number of the subpackage usually can't be back to 1%{?dist}.
Right.

> How should
> we treat this case?
I don't see any alternative to having to start with a %release !=
<old-version>%{?dist} or to play tricks with epochs (Which I'd rather
not recommend to do).

Ralf



--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 01-05-2008, 07:54 AM
Jindrich Novy
 
Default release of subpackage with version different from main rpm

On Wed, Jan 02, 2008 at 09:08:44AM -0600, Rex Dieter wrote:
> Mamoru Tasaka wrote:
>
> > I guess there are some packages of which subpackage rpms have versions
> > which are different from those of the main rpm.
> > For example, on rawhide perl has 4:5.8.8-32.fc8 EVR and its subpackage
> > perl-ExtUtils-MakeMaker has 0:6.30-32.fc8 EVR.
> >
> > On such case are there any policy for release number? For perl currently
> > the main perl rpm and its subpackages have the same release number.
> > However in other rpms the case may happen that only the version of
> > main rpm will be bumped where the version of its subpackage won't change.
> > In that case usually we want to switch the release number of main rpm
> > to 1%{?dist}, however if its subpackage has different version the release
> > number of the subpackage usually can't be back to 1%{?dist}. How should
> > we treat this case?
>
> imo, the simplest solutions for cases like this are:
> 1. don't munge versions for subpkgs, ie, subpkg EVR = main pkg EVR
> 2. where different Versions are desired, make these a *completely
> separate* pkg, not just a sub-pkg.

None of these approaches are possible in some cases, say TeXLive. The
distribution consists of many independent parts, but as a distribution it has
one huge tarball. Following your suggestion would lead to have a couple of
separate packages containing full tarball from which only a particular
part which is packaged is ripped off, which is quite wasteful IMO.

In case of one package and many subpackages, the "subpkg EVR = main pkg EVR" is
also not possible, because each bit has a different version, because
they are developed independently.

Why to strictly avoid subpackages with a different NEVR than the main one? I can
imagine many of situations where it makes perfectly sense, the one I
described is one of these.

Jindrich

--
Jindrich Novy <jnovy@redhat.com> http://people.redhat.com/jnovy/

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 01-06-2008, 01:02 PM
Patrice Dumas
 
Default release of subpackage with version different from main rpm

On Sun, Jan 06, 2008 at 03:36:13PM +0200, Axel Thimm wrote:
> On Sat, Jan 05, 2008 at 07:30:46PM -0500, Tom spot Callaway wrote:
>
> And given that tex distributions even very stable and solid ones like
> tetex can decide to disappear into thin air from one day to another, I
> wouldn't bind ourselves to versioning and naming of intermediate
> upstreams. E.g. I wouldn't even use texlive/tetex prefixes to
> subpackages and dependencies. After all a package requiring some
> version of LaTeX or dvips doesn't require that it comes from tetex,
> TeXlive etc., so the dependency should be kept subvendor-free.

There is a plan to have virtual provides for tex/latex, discussion
is at
https://bugzilla.redhat.com/show_bug.cgi?id=410401

> (The current packages go into the right direction wrt above, e.g.:
> texlive-2007-7
> texlive-afm-2007-7
> texlive-dvips-2007-7
> texlive-dviutils-2007-7
> texlive-latex-2007-7
> kpathsea-2007-7
> kpathsea-devel-2007-7
> xdvi-22.84.12-7
> dvipng-1.9-7
> mendexk-2.6e-7
> dvipdfm-0.13.2d-7
> dvipdfmx-0-7
> Ideally latex, dvips etc will also land into their "own" subpackage)

I don't think so. The package name should be what upstream is. It's up
to the virtual provides to provide vendor independance.

--
Pat

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 

Thread Tools




All times are GMT. The time now is 03:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org