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-05-2008, 11:00 AM
Patrice Dumas
 
Default release of subpackage with version different from main rpm

On Sat, Jan 05, 2008 at 07:59:40PM +0900, Mamoru Tasaka wrote:
> Jindrich Novy wrote, at 01/05/2008 05:54 PM +9:00:
>
> Well, it can be that one (huge) tarball has several sub-components which
> are developed independency and they has different versions _internally_
> however they are released in one tarball anyway?

Internally or not internally is not a simple matter. In the case of
texlive, for example, the softwares come from CTAN, in general or are
in teexlive svn taken from somewhere else. However it may happen
that texlive has become something like the new upstream... though
intermediate release may still happen out of texlive.

> Generally if one component of the tarball is updated (for example
> xdvi is updated from 22.84.12 to 22.84.13), then upstream should also bump the
> version of the tarball because even if only one component of the (huge)
> tarball is changed it means from external it means that the tarball is changed
> anyway (i.e. texlive must have version "2007.1", for example).
> If upstream releases new version of the tarball without changing the version
> but with changing one of the components, it is very confusing and in the case
> "we" (rpm packager) should change version intentionally (like ImageMagick).

This is not an issue with texlive, there is only one release a year
with change in version.

> IMO "version" of rpm should respect from what "tarball" the rpm is generated.
> For xdvi if providing "22.84.12" is preferable, it must be treated by
> vertial provides, i.e. the name of rpm should be "texlive-xdvi" with version
> "2007", with providing "xdvi = 22.84.12".

That's another option, but if we split it in the future we'll have to
add obsoletes and provides, this is avoided in the current situation.

It should be noted that for texlive some subpackages should be packaged
completly separately, but they were already in tetex, so I allowed
Jindrich to ship them with texlive. Still some are better taken from
texlive though they have their own veresioning.

--
Pat

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 01-05-2008, 12:01 PM
Axel Thimm
 
Default release of subpackage with version different from main rpm

On Sat, Jan 05, 2008 at 09:54:30AM +0100, Jindrich Novy wrote:
> 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.

texlive is a special case, there are not that many
in-between-upstreams that do a collection of other projects.

In general it is desirable to have one-tarball-one-specfile-one-
version setups. For texlive it would have meant to split up texlive
into its components and retarball them (or persuade upstream to do
so).

Since using texlive means relying on an in between upstream to do the
intergration work the above is nonsense, of course, so keep on the
subpackaging versioning as you do.

But other than texlive or maybe even the kernel (with many subsystems
having their own version) I don't think this applies to many other
examples, so we can special-case texlive and have otherwise a general
rule of thumb that "using different evr in subpackages is an
indication of something wrong".

Just as an example about the wrong setup: Look at how often rpm/popt
packages broke in their upgrade path in the past for having two
versions in a tarball - thank god we have finally two sources for them.
--
Axel.Thimm at ATrpms.net
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 01-06-2008, 12:36 PM
Axel Thimm
 
Default release of subpackage with version different from main rpm

On Sat, Jan 05, 2008 at 07:30:46PM -0500, Tom spot Callaway wrote:
> On 01/05/2008 Jason L Tibbitts III wrote:
> > If there's a component (of texlive, Perl, or whatever distro we're
> > repackaging) which we frequently feel like we need to update out of
> > sync with the distro that packages it, we shouldn't hesitate to
> > package it separately.
>
> Well, yes and no. This is a place where I've got to assume that upstream
> has a good reason for bundling these components together in the same
> tarball. If one of those bundled components frequently needs updates, we
> should be having dialogs with upstream about:
>
> A. Whether that component needs to be bundled in
> B. Whether the supertarball needs to be updated more often
> C. What the effect of Fedora updating the component will be on the
> supportability of the whole, from an upstream perspective
>
> With that data, when needed and with upstream support, we shouldn't shy
> away from packaging it separately.

I guess the question is whether to keep it technically possible to
perform such updates. If you have a supertarball and use for all
subpackages a common evr, even one that doesn't match the real
upstream's subpackages' versioning, then for updating one subpackage
you need to update them all, or you would have to package an external
package or upstream foo using a false version, e.g. adapting a version
scheme like the superpackage's. And you would run into evr races with
the supertarball.

So it boils down to either total commitment to the intermediate
upstream's updating and versioning or keeping separate versioning
matching the true upstream thus allowing to deviate from the
intermediate upstream. All in all it's about the future freedom of
choice.

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.

IOT the tetex/texlive prefixing is separate from
perl/python/... prefixing as tetex/texlive is a vendor string, not the
real universe which would probably be simply "tex".

(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)
--
Axel.Thimm at ATrpms.net
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 01-06-2008, 06:44 PM
Axel Thimm
 
Default release of subpackage with version different from main rpm

On Sun, Jan 06, 2008 at 03:02:51PM +0100, Patrice Dumas wrote:
> > (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.

Upstream versions latex with version "2005/12/01" (one could argue
whether fixltx2e makes that "2006/03/24" instead).

This is quite distinct from texlive-latex-2007. Or seen from a
different perspective: If naming/versioning latex as
texlive-latex-2007 is fine, why isn't texlive-xdvi-2007 fine as well?

> It's up to the virtual provides to provide vendor independance.

Of course, if you

a) have these virtual provides
b) make this public enough that packagers use them instead of the
package names (and really how many packagers check to see whether
some dependent on package provides some virtual entities that they
should pull in instead, and more importantly how certain can this
packager be that this virtual Provides: will be around long enough
and not have his package broken by the next texlive package
update?).
c) rpm, yum and friends deal better with virtual provides vs real
entities than they do now. Thankfully the aged bug on packages
auto-obsoleting when providing a virtual dependency has been
recently fixed, but not yet in the rpms we use (I think so at
least, perhaps F8 has the fix), and more importantly it created
confusion and aversion to using virtual provides for upgrade paths
and that's what this is about.

Instead it would be better to have the real package names prompty
display to other packagers what they should require and keep
compatibility provides internally.
--
Axel.Thimm at ATrpms.net
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 01-06-2008, 09:22 PM
Patrice Dumas
 
Default release of subpackage with version different from main rpm

On Sun, Jan 06, 2008 at 09:44:38PM +0200, Axel Thimm wrote:
>
> Upstream versions latex with version "2005/12/01" (one could argue
> whether fixltx2e makes that "2006/03/24" instead).

That could be a good idea for numbering the virtual provides in my
opinion.

> This is quite distinct from texlive-latex-2007. Or seen from a
> different perspective: If naming/versioning latex as
> texlive-latex-2007 is fine, why isn't texlive-xdvi-2007 fine as well?

Because xdvi is really a distinct package with its own upstream. It has
just been submitted anyway, so this issue won't be there for long.

> > It's up to the virtual provides to provide vendor independance.
>
> Of course, if you
>
> a) have these virtual provides
> b) make this public enough that packagers use them instead of the
> package names (and really how many packagers check to see whether
> some dependent on package provides some virtual entities that they
> should pull in instead, and more importantly how certain can this
> packager be that this virtual Provides: will be around long enough
> and not have his package broken by the next texlive package
> update?).

We will make sure that only the virtual provides are used. Hopefully
it will become a guideline. Just like the python and emacs virtual
provides.

> c) rpm, yum and friends deal better with virtual provides vs real
> entities than they do now. Thankfully the aged bug on packages
> auto-obsoleting when providing a virtual dependency has been
> recently fixed, but not yet in the rpms we use (I think so at
> least, perhaps F8 has the fix), and more importantly it created
> confusion and aversion to using virtual provides for upgrade paths
> and that's what this is about.

It has to work rergardless of texlive/tex. It is a requirement for
alternate provides.

> Instead it would be better to have the real package names prompty
> display to other packagers what they should require and keep
> compatibility provides internally.

Why internally? They are here exactly for independence with regard with
tex distribution vendor, so must be virtual. (It is certainly not for
soon, but we could even imagine packaging 2 tex distros in parallel in
fedora).

Having a) and b) is the plan, as for c) it has to be fixed anyway. In th
emean time, the tetex-* provides can be kept (and will have to for a
long period of time in EPEL anyway).

--
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 11:01 AM.

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