[gentoo-dev] XFCE package names

[gentoo-dev] XFCE package names

[purslow]

XFCE 4 has been out for  nrly 6 mth  & is proving very satisfactory.
XFCE 3 is no longer being developed or AFAIK supported.
however on Gentoo, 'emerge xfce' still gives you XFCE 3.18.3 ,
while you have to say 'emerge xfce4' to get XFCE 4.0.1 (4.0.3 is latest).

can those responsible please revise the package names (surely no effort) ?
'xfce' sb XFCE 4.0.n , while 'xfce3' shd get the obsolete XFCE 3.18.3 .

-- 
========================,,============================================
SUPPORT     ___________//___,  Philip Webb : purslow@chass.utoronto.ca
ELECTRIC   /] [] [] [] [] []|  Centre for Urban & Community Studies
TRANSIT    `-O----------O---'  University of Toronto

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] XFCE package names

[Brandon Hale]

On (01/18/04 15:17), purslow@sympatico.ca wrote:
> XFCE 4 has been out for  nrly 6 mth  & is proving very satisfactory.
> XFCE 3 is no longer being developed or AFAIK supported.
> however on Gentoo, 'emerge xfce' still gives you XFCE 3.18.3 ,
> while you have to say 'emerge xfce4' to get XFCE 4.0.1 (4.0.3 is latest).
> 
> can those responsible please revise the package names (surely no effort) ?

If you've ever used cvs, which we do for our portage tree, you will know
that moving packages is far more painful than the "no effort" you suppose. Due to the number of packages that make up XFCE, suggesting such a large move would not be taken lightly.

This has come up before, at which time the answer was this:
xfce.org refers to their newest release as "xfce4" vs xfce.

I can see logic in both sides of this argument, but hopefully we won't go
back and forth ad naseum on a non-issue. I will consider this further,
and speak w/ the package's maintainer on the issue when he returns.

> 'xfce' sb XFCE 4.0.n , while 'xfce3' shd get the obsolete XFCE 3.18.3 .
Ideally, both packages would share the same name. Someone wanting xfce 3.x
would have to mask 4.x in /etc/portage/package.mask

Regards,
--tseng

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] XFCE package names

[neuron]

Could create a fake xfce ebuild, that says pick xfce3/xfce4 and create "new" xfce3 ebuild using the old xfce ebuild.

> On (01/18/04 15:17), purslow@sympatico.ca wrote:
> > XFCE 4 has been out for  nrly 6 mth  & is proving very satisfactory.
> > XFCE 3 is no longer being developed or AFAIK supported.
> > however on Gentoo, 'emerge xfce' still gives you XFCE 3.18.3 ,
> > while you have to say 'emerge xfce4' to get XFCE 4.0.1 (4.0.3 is latest).
> > 
> > can those responsible please revise the package names (surely no effort) ?
> 
> If you've ever used cvs, which we do for our portage tree, you will know
> that moving packages is far more painful than the "no effort" you suppose. Due to the number of packages that make up XFCE, suggesting such a large move would not be taken lightly.
> 
> This has come up before, at which time the answer was this:
> xfce.org refers to their newest release as "xfce4" vs xfce.
> 
> I can see logic in both sides of this argument, but hopefully we won't go
> back and forth ad naseum on a non-issue. I will consider this further,
> and speak w/ the package's maintainer on the issue when he returns.
> 
> > 'xfce' sb XFCE 4.0.n , while 'xfce3' shd get the obsolete XFCE 3.18.3 .
> Ideally, both packages would share the same name. Someone wanting xfce 3.x
> would have to mask 4.x in /etc/portage/package.mask
> 
> Regards,
> --tseng
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] XFCE package names

[Paul de Vrieze]

> XFCE 4 has been out for  nrly 6 mth  & is proving very satisfactory.
> XFCE 3 is no longer being developed or AFAIK supported.
> however on Gentoo, 'emerge xfce' still gives you XFCE 3.18.3 ,
> while you have to say 'emerge xfce4' to get XFCE 4.0.1 (4.0.3 is latest).
>
> can those responsible please revise the package names (surely no effort) ?
> 'xfce' sb XFCE 4.0.n , while 'xfce3' shd get the obsolete XFCE 3.18.3 .
>

Let me also add that it is policy to not use version numbers in the
package names at all. We have slots for them, so no xfce3, just xfce with
a 3 version and a 4 version

Paul


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] XFCE package names

[John Nilsson]

[-- Attachment #1: Type: text/plain, Size: 357 bytes --]


> If you've ever used cvs, which we do for our portage tree, you will know
> that moving packages is far more painful than the "no effort" you suppose.
> Due to the number of packages that make up XFCE, suggesting such a large  
> move
> would not be taken lightly.

Is there any particular feature in cvs that subversion could not provide?

/John

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] XFCE package names

[Mike Williams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 19 January 2004 15:18, John Nilsson wrote:
> Is there any particular feature in cvs that subversion could not provide?

A stable DB format? :)

- -- 
Mike Williams
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAC/ciInuLMrk7bIwRAoUKAJkBF/hlc5H8//9UGJNoYTsFCMdj0gCglUpr
tGP/QDDSe7QxUjrOf5N5NEU=
=HZYR
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] XFCE package names

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 596 bytes --]

On Monday 19 January 2004 16:26, Mike Williams wrote:
> On Monday 19 January 2004 15:18, John Nilsson wrote:
> > Is there any particular feature in cvs that subversion could not provide?
>
> A stable DB format? :)

That and the fact that the database is very very big. That would make 
subversion dumps quite painfull. Further subversion is not really good in 
such big repositories in any case, although that might have improved since I 
last tested importing a portage tree.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] XFCE package names

[foser]

On Mon, 2004-01-19 at 16:18, John Nilsson wrote:
> > If you've ever used cvs, which we do for our portage tree, you will know
> > that moving packages is far more painful than the "no effort" you suppose.
> > Due to the number of packages that make up XFCE, suggesting such a large  
> > move
> > would not be taken lightly.
> 
> Is there any particular feature in cvs that subversion could not provide?

Tseng's initial statement is a bit misleading, it has nothing to do with
cvs. It's a move that can and should be handled by portage, but it's
still tedious.

I personally do agree though that this (XFCE4) naming convention has
been wrong from the start and have brought it up before on IRC. Gentoo,
unlike some binary based distros, has no reason to use version numbers
in package names because of the SLOTs system and we should make as
extensive use of this as possible.

That doesn't change the fact that this is a lot of work and it's up to
the maintainers to find time to do this. It has no immediate importance,
but it should be on their TODO.

- foser


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] XFCE package names

[Ævar Arnfjörð Bjarmason]

[-- Attachment #1: Type: text/plain, Size: 1661 bytes --]

Paul de Vrieze wrote:
> On Monday 19 January 2004 16:26, Mike Williams wrote:
> 
>>On Monday 19 January 2004 15:18, John Nilsson wrote:
>>
>>>Is there any particular feature in cvs that subversion could not provide?
>>
>>A stable DB format? :)
> 
> 
> That and the fact that the database is very very big. 

Attached is a recent test i did on subversion regarding exactly this, the the
size of the repository I came to the same conclusion as you (the db is big) in
this case 161MB for a raw import of portage versus CVS's 70MB.

However this is due to the Berkley DB leaving behind a lot of log files which
in all normal use are usless and can be safely deleted. (these are not the
commit-diffs)

After i deleted these unused log-files the previously 161MB subversion
repository of portage took 49MB or more then threefold reduction in size
without any loss of version info or files.
More info can be found in the subversion manual at -> project_faq.html#bdblogs
which deals specifically with why the repository gets so big.

The subversion admin can regularly remove these logfiles from the repository
through the use of a cron job in older versions or just leave the default
log-pruning on in versions >=0.35.

So not only was the statement about subversions database being bigger wrong,
its quite the opposite; its smaller.

   > That would make
   > subversion dumps quite painfull. Further subversion is not really good in
   > such big repositories

Elaborate, why does it not handle the big ones well?

   > in any case, although that might have improved since I last tested
   > importing a portage  tree.
   >
   > Paul
   >

Ævar Arnfjörð Bjarmason



[-- Attachment #2: cvsVSsvn --]
[-- Type: text/plain, Size: 1669 bytes --]

# Making dirs for vcs
$ mkdir -p /home/vcs/portage_cvs
$ mkdir -p /home/vcs/portage_svn

# Making dirs for portage
$ mkdir /home/jeedo/portage
$ cd /home/jeedo/portage

# Cleaning portage
$ cp -R /usr/portage/*-* .
$ find -type d -iname 'files' -exec rm -rf {} \;
$ find -type f -iname 'Changelog' -exec rm -rf {} \;
$ find -type f -iname 'Manifest' -exec rm -rf {} \;

# Checking size
$ cd /home/jeedo/portage
$ du -sh && du -s
70M     .
70867   .

# Importing to CVS
$ export CVSROOT="/home/vcs/portage_cvs"
$ cvs init
$ time cvs import -m "Initial Import" portage vendor start
[...]
real    1m11.072s
user    0m4.380s
sys     0m11.210s

# Importing to SVN
$ svnadmin create /home/vcs/portage_svn/
$ time svn import -m "First import" ./ file:///home/vcs/portage_svn/
[...]
real    12m58.771s
user    2m10.090s
sys     1m3.130s

# Checking the size of newly-imported stuff
$ cd /home/vcs/
$ du -sh * && du -s *
70M     portage_cvs
161M    portage_svn
71456   portage_cvs
164575  portage_svn


# Making working directories
$ mkdir /home/jeedo/portage_work_cvs
$ mkdir /home/jeedo/portage_work_svn

# Checking out the CVS tree
$ export CVSROOT="/home/vcs/portage_cvs"
$ cd /home/jeedo/portage_work_cvs
$ time cvs co portage
[...]
real    1m40.417s
user    0m12.780s
sys     0m36.700s

# Checking out the SVN tree
$ cd /home/jeedo/portage_work_svn
$ time svn co file:///home/vcs/portage_svn/
[...]
real    6m20.541s
user    1m57.390s
sys     1m41.810s

# Conclusion
Importing to SVN takes almost 11 times as much time as importing to CVS (
	778.771/71.072 
	10.95749380909500225123
)

And takes more than 2 times as much space (
	164575/71456
	2.3031655844155844155
)




[-- Attachment #3: Type: text/plain, Size: 37 bytes --]

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] XFCE package names

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

On Saturday 24 January 2004 17:37, Ævar Arnfjörð Bjarmason wrote:
> Attached is a recent test i did on subversion regarding exactly this, the
> the size of the repository I came to the same conclusion as you (the db is
> big) in this case 161MB for a raw import of portage versus CVS's 70MB.
>
> However this is due to the Berkley DB leaving behind a lot of log files
> which in all normal use are usless and can be safely deleted. (these are
> not the commit-diffs)
>
> After i deleted these unused log-files the previously 161MB subversion
> repository of portage took 49MB or more then threefold reduction in size
> without any loss of version info or files.
> More info can be found in the subversion manual at ->
> project_faq.html#bdblogs which deals specifically with why the repository
> gets so big.
>
> The subversion admin can regularly remove these logfiles from the
> repository through the use of a cron job in older versions or just leave
> the default log-pruning on in versions >=0.35.
>
> So not only was the statement about subversions database being bigger
> wrong, its quite the opposite; its smaller.
>
>    > That would make
>    > subversion dumps quite painfull. Further subversion is not really good
>    > in such big repositories
>
> Elaborate, why does it not handle the big ones well?
>

I have not tested it in a long while. What happened was that IF I was able to 
actually check in the whole tree into the repository checking out would both 
take too much time and fail somewhere in the meantime on some lock or 
out-of-memory error.

It can very well be that this has been fixed by now, but I didn't check.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] XFCE package names

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

On Sat, Jan 24, 2004 at 04:37:35PM +0000, ?var Arnfj?r? Bjarmason wrote:
> Attached is a recent test i did on subversion regarding exactly this,
> the the size of the repository I came to the same conclusion as you
> (the db is big) in this case 161MB for a raw import of portage versus
> CVS's 70MB.
However, 70MB is NOT the actual amount of data, as if we do use
subversion, we WILL want our old CVS history.  The CVS repository is
currently 899Mb in size. The gentoo-x86 module that you see as the
portage tree is 572Mb.

Another major question I have, is how will it deal with lots of
concurrent access? CVS excels in this regard, as it does locking on a
per-file basis for writing (no locks on reading).
AFAIK with BDB databases there is locking only for the entire database,
so there may be an issue of a LOT more lock contention which would slow
things down a lot. There are very seldom less than four simultanous cvs
actions going on, and most of the time things are much busier than that
(I've seen the server having 20 cvs operations going on at the same
time).

A normal CVS checkout of the gentoo-x86 from the tree (locally on the
CVS server) takes 8 minutes. Your SVN co took 3.8 times as long as the
CVS checkout so thats nearly 30 minutes to do a checkout :-(.

I am really worried about lock contention however. We already keep all
of the cvs locks on a tmpfs filesystem for speed and disk fragmentation
reasons.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] XFCE package names

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Sunday 25 January 2004 04:02, Robin H. Johnson wrote:
> A normal CVS checkout of the gentoo-x86 from the tree (locally on the
> CVS server) takes 8 minutes. Your SVN co took 3.8 times as long as the
> CVS checkout so thats nearly 30 minutes to do a checkout :-(.

Both take too long to my sense. Which is basically what I experienced before. 

> I am really worried about lock contention however. We already keep all
> of the cvs locks on a tmpfs filesystem for speed and disk fragmentation
> reasons.

I don't know how subversion does this, but you are right that it is possible 
that subversion does global locking. In that case subversion is out of the 
question.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] XFCE package names

[Ævar Arnfjörð Bjarmason]

Paul de Vrieze wrote:
> On Sunday 25 January 2004 04:02, Robin H. Johnson wrote:
> 
>>A normal CVS checkout of the gentoo-x86 from the tree (locally on the
>>CVS server) takes 8 minutes. Your SVN co took 3.8 times as long as the
>>CVS checkout so thats nearly 30 minutes to do a checkout :-(.
> 
> 
> Both take too long to my sense. Which is basically what I experienced before. 

Well thats 30 minutes for the whole tree initially, as i understand thats 
because svn is doing alot more in the background than CVS is, anyway i might 
just have not known how to operate it correctly so speeding it up might be a 
possibility.

However note that thats 30 minutes for the whole tree, just grabbing the part 
you're going to be working on or even updating your working copy will never 
take that long once you have cheked it out initially.

$ find /usr/portage -maxdepth 1 -iname '*-*'|sort|wc -l
104

So grabbing a whole subbranch is still just 16 seconds on average (of course 
they differ in size)

It could be better but its not that bad, especially considering all the 
atvantages you get.

>>I am really worried about lock contention however. We already keep all
>>of the cvs locks on a tmpfs filesystem for speed and disk fragmentation
>>reasons.
> 
> 
> I don't know how subversion does this, but you are right that it is possible 
> that subversion does global locking. In that case subversion is out of the 
> question.
> 
> Paul
> 

--
gentoo-dev@gentoo.org mailing list