public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Tom Wesley <tom@tomaw.org>
To: gentoo-dev@robin.gentoo.org
Subject: Re: [gentoo-dev] KDE split ebuilds
Date: Wed, 16 Mar 2005 22:07:23 +0000	[thread overview]
Message-ID: <4238AE1B.7030301@tomaw.org> (raw)
In-Reply-To: <200503162229.21736.danarmak@gentoo.org>

Dan Armak wrote:
> On Tuesday 15 March 2005 21:25, Tom Wesley wrote:
> 
>>Hey
>>
>>I've seen several queries regarding KDE's new split ebuilds and the
>>version numbers used for specific packages.  It seems that all of the
>>KDE 3.4 packages have been versioned as 3.4.
>>
>>Should kmail, kopete etc not be using their own version numbers with the
>>meta-packages being versioned based on the kde release number?  
>>IMO this would make more sense, especially when reading the kopete website, 
>>finding the latest version is 0.9.2 and then noticing that portage only 
>>has 3.4.
> 
> In my experience most KDE users have no idea offhand what the individual app 
> versions are and which versions belong to which kde.org release. They'd be 
> confused.
> 
> If a lot of users told me I'm wrong, I guess I'd be willing to concede this 
> point...
> 
> BTW, what do other distros use?

The only other distro I have recollection of is Debian and they have the 
packages at the version number of the software.  That is, they have a 
kmail-1.5 being part of kde-3.3.x [1]

> 
> Another problem is that there are a few KDE devs who are the same: they don't 
> bother to put real version numbers on their apps (and especially libs), and 
> they stay stuck at 0.0.1, or don't always receive a version number upgrade 
> when they change. I can't find an example offhand now, but I remember seeing 
> such before...

Probably.  Dated version numbers could perhaps help?  Stuff in 
kdenonbeta probably suffers from never being released or versioned.

> 
> And a third problem: it'd make it much easier for us to make a versioning/dep 
> mistake (think about updating 300 differently-schemed version numbers) 
> without noticing.
> 

I can't disagree that p'masking a bucket-load of packages, all at 
different versions will be a pain.  Also, upgrading etc may require a 
small army of gnome's (pun intended) to complete the task in a timely 
manner.

Do any kde applications release outside of kde's main releases?  (I have 
a vague recollection of kopete doing this, but no others)

   1: http://packages.debian.org/unstable/mail/kmail
-- 
Tom Wesley <tom@tomaw.org>
--
gentoo-dev@gentoo.org mailing list


  parent reply	other threads:[~2005-03-16 22:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-15 19:25 [gentoo-dev] KDE split ebuilds Tom Wesley
2005-03-16 19:49 ` Sven Vermeulen
2005-03-16 20:29 ` Dan Armak
2005-03-16 21:48   ` Francesco Riosa
2005-03-17 19:03     ` Dan Armak
2005-03-16 22:07   ` Tom Wesley [this message]
2005-03-16 22:17     ` Graham Murray
2005-03-17 19:11     ` Dan Armak
2005-03-17 19:13       ` Tom Wesley
2005-03-18 16:21   ` [gentoo-dev] " Duncan
2005-03-19 16:26     ` Dan Armak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4238AE1B.7030301@tomaw.org \
    --to=tom@tomaw.org \
    --cc=gentoo-dev@gentoo.org \
    --cc=gentoo-dev@robin.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox