[gentoo-dev] additional files in portage tree

[gentoo-dev] additional files in portage tree

[Ben Lutgens]

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

Hi all, I am proposing we add a new file to the portage tree directories. I
was thinking something like the pkg_descr files in freebsd ports. It could
have a slightly more detailed description, the install process ( from the
portage point of view ) as well as homepage and ftp urls and possibly a
brief gentoo-changelog. It could look something like this.

#-------------------------

Description: gkrellm-0.9.1 - A nifty app that combines a system load
monitor, mem, swap, fs, and net monitors (among others) into a single
process for X. It's themeable and will take plugins ( i.e. gkrellmmms,
gkrellm-wireless etc.). 

Homepage: http://www.gkrellm.org 
			 ftp://www.gkrellm.org

Install Process: This makefile works well so all I had to do was add the
dodoc statements
# [ or conversely ]
# Install Process: Inhospitable makefile, had to completely install it by
# hand with dobin etc. Submitted patch to makefile upstream.

Changes:
gkrellm-0.5.1-r4: 
	* fixed the doc install
	* Info files going into right place now


Caveats: Installing this will break your fingers in three places and
possibly cause X to dump large core files in the current dir every 7
seconds. Also will overwrite any config files you have in /etc/exim/

Contributors: My mom submitted a patch for the Makefile that I apply here.

#------ SNIP

I just think it'd be nice to have a file that we can less to find out what
a package is, sometimes the name isn't enough as I can't possibly keep
straight everything and the DESCRIPTION in the ebuild isn't great since
noone wants to clutter everything up.

I'm also not suggesting we take the next 3 months to write these for the
existing packages, just adding them for new ones or possibly when updating.


-- 
Ben Lutgens		
Sistina Software Inc.	

What's the difference between root and God ?
God doesn't think that he is root. 

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

Re: [gentoo-dev] additional files in portage tree

[Daniel Robbins]

On Wed, Aug 08, 2001 at 12:05:25PM -0500, Ben Lutgens wrote:

> I just think it'd be nice to have a file that we can less to find out what
> a package is, sometimes the name isn't enough as I can't possibly keep
> straight everything and the DESCRIPTION in the ebuild isn't great since
> noone wants to clutter everything up.

This could be helpful.  It also looks like a good candidate for XML, which
would also make it easy to get this information on the Web site.  Let's see
what other people think about the idea.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] additional files in portage tree

[Parag Mehta]

Hi Ben!

* Ben Lutgens assembled some ascibets to say:
Ben >Hi all, I am proposing we add a new file to the portage tree directories. I
Ben >was thinking something like the pkg_descr files in freebsd ports. It could
Ben >have a slightly more detailed description, the install process ( from the
Ben >portage point of view ) as well as homepage and ftp urls and possibly a
Ben >brief gentoo-changelog. It could look something like this.
Ben >I just think it'd be nice to have a file that we can less to find out what
Ben >a package is, sometimes the name isn't enough as I can't possibly keep
Ben >straight everything and the DESCRIPTION in the ebuild isn't great since
Ben >noone wants to clutter everything up.
Ben >
Ben >I'm also not suggesting we take the next 3 months to write these for the
Ben >existing packages, just adding them for new ones or possibly when updating.

I'm all for it.

also it would be nice if it could be interactive in way that when :

emerge foo.ebuild
it shows the pkg_descr()
thenruns the emerge --pretend foo.ebuild
and then asks the user whether to go ahead or not ?

and the user can bypass the interactivity by passing one more parameter as :
emerge --nopretend foo.ebuild

which shows the pkg_descr()
and then goes ahead and merges the pkg.

best regards,

pm
--
Developer		 <pm@gentoo.org>
Gentoo Linux		http://gentoo.org

#exclude <windows.h>

Re: [gentoo-dev] additional files in portage tree

[Dan Armak]

On Wednesday 08 August 2001 20:25, you wrote:
> Hi Ben!
>
> * Ben Lutgens assembled some ascibets to say:
> Ben >Hi all, I am proposing we add a new file to the portage tree
> directories. I Ben >was thinking something like the pkg_descr files in
> freebsd ports. It could Ben >have a slightly more detailed description, the
> install process ( from the Ben >portage point of view ) as well as homepage
> and ftp urls and possibly a Ben >brief gentoo-changelog. It could look
> something like this.
> Ben >I just think it'd be nice to have a file that we can less to find out
> what Ben >a package is, sometimes the name isn't enough as I can't possibly
> keep Ben >straight everything and the DESCRIPTION in the ebuild isn't great
> since Ben >noone wants to clutter everything up.
> Ben >
> Ben >I'm also not suggesting we take the next 3 months to write these for
> the Ben >existing packages, just adding them for new ones or possibly when
> updating.
>
> I'm all for it.
>
> also it would be nice if it could be interactive in way that when :
>
> emerge foo.ebuild
> it shows the pkg_descr()
> thenruns the emerge --pretend foo.ebuild
> and then asks the user whether to go ahead or not ?
>
> and the user can bypass the interactivity by passing one more parameter as
> : emerge --nopretend foo.ebuild
What you want is reverse the default value of pretend emerges (i.e. pretend 
by default) and of interactiveness (which is currently non-existent, but by 
your system  a user would have to confirm building after running emerge). 
IMHO, and as a personal opinion, I like things better the way they are now. 
But if it comes to that I suppose this can be made configurable easily enough.

As for the description files: I think there'll always be large blanks and 
ebuilds without descriptions. The important thing will be to remember that 
there were no descriptions and now there are some. New users might fall to 
thinking there are "supposed" to be descriptions but usually aren't, and 
psychologically that's a worse impression than no descriptions at all. I 
don't know how true-to-life I'm picturing the users here :-)
Except for that it obviously can only help, so let's go ahead with it!


-- 

Dan Armak
Gentoo Linux Developer, Desktop Team
Matan, Israel

Re: [gentoo-dev] additional files in portage tree

[Mikael Hallendal]

Hi!

The problem with xml is that it's hard to read without a tool, we
could however easily write such a tool that we use for viewing those
files. So I'd say that an xml-file describing the package would be
nice since it can then be used on the web for browsing available
packages.

Regards,
Mikael Hallendal

Daniel Robbins <drobbins@gentoo.org> writes:

> On Wed, Aug 08, 2001 at 12:05:25PM -0500, Ben Lutgens wrote:
> 
> > I just think it'd be nice to have a file that we can less to find
> >out what a package is, sometimes the name isn't enough as I can't
> >possibly keep straight everything and the DESCRIPTION in the ebuild
> >isn't great since noone wants to clutter everything up.
> 
> This could be helpful.  It also looks like a good candidate for XML,
> which would also make it easy to get this information on the Web site.
> Let's see what other people think about the idea.
> 
> Best Regards,
> 
> -- 
> Daniel Robbins					<drobbins@gentoo.org>
> Chief Architect/President			http://www.gentoo.org 
> Gentoo Technologies, Inc.			
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@cvs.gentoo.org
> http://cvs.gentoo.org/mailman/listinfo/gentoo-dev

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] additional files in portage tree

[tekno]

My understanding of the purpose of the pkg-descr files is not to provide
yet-another-"cryptic" file that gives information about the package.  It
would seem to me, then, that providing an xml file for the end user
would defeat this purpose... perhaps have an xml file that is parsed to
generate the pkg-descr file for the end user as well as an html file for
the web/wiki or whatever, but I, for one, would like to be able to use
my standard tools on the file and get results that mean something.

find /usr/portage -name "pkg-descr" -exec grep -H "somestring" {} \;
less pkgname/pkg-descr
etc.

just my $0.02

Justin

On Thu, Aug 09, 2001 at 12:44:46AM +0200, Mikael Hallendal wrote:
> Hi!
> 
> The problem with xml is that it's hard to read without a tool, we
> could however easily write such a tool that we use for viewing those
> files. So I'd say that an xml-file describing the package would be
> nice since it can then be used on the web for browsing available
> packages.
> 
> Regards,
> Mikael Hallendal
> 
> Daniel Robbins <drobbins@gentoo.org> writes:
> 
> > On Wed, Aug 08, 2001 at 12:05:25PM -0500, Ben Lutgens wrote:
> > 
> > > I just think it'd be nice to have a file that we can less to find
> > >out what a package is, sometimes the name isn't enough as I can't
> > >possibly keep straight everything and the DESCRIPTION in the ebuild
> > >isn't great since noone wants to clutter everything up.
> > 
> > This could be helpful.  It also looks like a good candidate for XML,
> > which would also make it easy to get this information on the Web site.
> > Let's see what other people think about the idea.
> > 
> > Best Regards,
> > 
> > -- 
> > Daniel Robbins					<drobbins@gentoo.org>
> > Chief Architect/President			http://www.gentoo.org 
> > Gentoo Technologies, Inc.			
> > 
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@cvs.gentoo.org
> > http://cvs.gentoo.org/mailman/listinfo/gentoo-dev
> 
> -- 
> Mikael Hallendal                micke@codefactory.se
> CodeFactory AB                  http://www.codefactory.se/
> Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@cvs.gentoo.org
> http://cvs.gentoo.org/mailman/listinfo/gentoo-dev

-- 
[]------------------------------------------------------------------[]
||       jbramley@vt.edu      tekno@vt.edu      just1@tfn.net       ||
||       AIM:eZZeWeZZa ICQ:21584649 IRC:TeknoFobe IRC:Loc-Dog       ||
[]------------------------------------------------------------------[]

Re: [gentoo-dev] additional files in portage tree

[Mikael Hallendal]

tekno@vt.edu writes:

> My understanding of the purpose of the pkg-descr files is not to
> provide yet-another-"cryptic" file that gives information about the
> package.  It would seem to me, then, that providing an xml file for
> the end user would defeat this purpose... perhaps have an xml file
> that is parsed to generate the pkg-descr file for the end user as well
> as an html file for the web/wiki or whatever, but I, for one, would
> like to be able to use my standard tools on the file and get results
> that mean something.
> 
> find /usr/portage -name "pkg-descr" -exec grep -H "somestring" {} \;
> less pkgname/pkg-descr etc.

Yes, that was what I meant by XML not be to userfriendly for a guy
using less. But we could easily hack together a tool for viewing the
file (nicely formatted too/colorized if we want) that you use instead
of less. So that you instead perhaps use something like:

'edesc pkgname' or something

Your way of doing it also seems totally right for me, to write it in
XML and generate a textfile from it.

Regards,
Mikael Hallendal

-- 
Mikael Hallendal                micke@codefactory.se
CodeFactory AB                  http://www.codefactory.se/
Office: +46 (0)8 587 583 05     Cell: +46 (0)709 718 918

Re: [gentoo-dev] additional files in portage tree [Improving Portage]

[Karl Trygve Kalleberg]

On Thu, Aug 09, 2001 at 12:44:46AM +0200, Mikael Hallendal wrote:
> Hi!
> 
> The problem with xml is that it's hard to read without a tool, we
> could however easily write such a tool that we use for viewing those
> files. So I'd say that an xml-file describing the package would be
> nice since it can then be used on the web for browsing available
> packages.

The problem with not using XML is that we have to make yet another file 
format parser, which we will have to maintain.

What's more, for other people to be able to make use of the description
files, they'll have to concoct their own parsers or use ours. If we want
them to use ours, we will have to make bindings for it to Perl, Python,
C, C++ and Java, preferrably other languages as well.

We get all this for free when using XML, since it's widely supported by
all non-trivial (and many trivial) languages.

However, it's a pain in the butt to write/edit and to some extend more 
difficult to read than a format tuned for human reading.

This is a known problem with no perfect solution. In fact, XML (or S-exp)
is as close as we've gotten to date.


In my opinion, we really attack this problem from the completely wrong end: 
we start by describing not only tools/technology we want to use, but also 
the specific storage of the data before we even know what we want to extend 
Portage with in the long term.

Better package descriptions is just one little part of it all. We also want
a graphical package tool, bug reporting, feature requests, regression testing,
an automatic package verifier that catches many of the nasty things (like ebuild 
foo install installing in /usr instead of ${D}/usr), bindings/exports of the 
package database to tools outside Portage, etc, etc.

We seem to be at a stage where our entire user population is extremely 
well-versed in unix, have a lot of experience to bring to the table, and are 
prepared to suffer some major restructurings in vital parts of the system (mainly 
Portage).

If anybody have any thoughts on this, we should get them all out now. I'll try to 
maintain them in some form for design document on the gentoo.org.



Regards,

Karl T

[gentoo-dev] Minicom does not build on my system...

[Thomas Landmann]

On my system, "emerge net-dialup/minicom/minicom-1.83.1.ebuild" dies with
the following output:

make -C po
make[1]: Entering directory
`/tmp/portage/minicom-1.83.1/work/minicom-1.83.1/src/po'
xgettext --default-domain=minicom \
          --add-comments --keyword=_ --keyword=N_ ../main.c ../minicom.c
../config.c ../updown.c ../dial.c ../help.c ../rwconf.c ../file.c
../getsdir.c ../ipc.c ../script.c ../windiv.c
if cmp -s minicom.po minicom.pot; then \
    rm -f minicom.po; \
else \
    mv minicom.po minicom.pot; \
fi
msgfmt -o pt_BR.mo pt_BR.po
msgfmt -o fi_FI.mo fi_FI.po
msgfmt -o ja.mo ja.po
ja.po: warning: Charset "euc-japanese" is not a portable encoding name.
                Message conversion to user's charset might not work.
cc ujis2sjis.c -o ujis2sjis
./ujis2sjis <ja.po >ja_JP.SJIS.po
msgfmt -o ja_JP.SJIS.mo ja_JP.SJIS.po
ja_JP.SJIS.po: warning: Charset "euc-japanese" is not a portable encoding
name.
                        Message conversion to user's charset might not work.
msgfmt -o fr.mo fr.po
msgfmt -o pl.mo pl.po
msgfmt -o ko.mo ko.po
ko.po:131: invalid multibyte sequence
ko.po:917: invalid multibyte sequence
ko.po:1095: invalid multibyte sequence
ko.po:1992: invalid multibyte sequence
ko.po:2039: invalid multibyte sequence
found 5 fatal errors
make[1]: *** [ko.mo] Error 1
make[1]: Leaving directory
`/tmp/portage/minicom-1.83.1/work/minicom-1.83.1/src/po'
make: *** [po] Error 2

!!! ERROR: the make command did not complete successfully.
!!! ("make")
!!! Since this is a critical task, ebuild will be stopped.

!!! emerge aborting on
/usr/portage/net-dialup/minicom/minicom-1.83.1.ebuild .

Any help would be greatly appreciated.

Thanks,

Tom

RE: [gentoo-dev] Minicom does not build on my system...

[Thomas Landmann]

I commented out "PO    = po" in the Makefile and it compiled.

This is likely not the correct fix, however.

Tom

> -----Original Message-----
> From: gentoo-dev-admin@cvs.gentoo.org
> [mailto:gentoo-dev-admin@cvs.gentoo.org]On Behalf Of Thomas Landmann
> Sent: Friday, August 10, 2001 3:25 PM
> To: gentoo-dev@cvs.gentoo.org
> Subject: [gentoo-dev] Minicom does not build on my system...
> 
> 
> On my system, "emerge net-dialup/minicom/minicom-1.83.1.ebuild" dies with
> the following output:
> 
> make -C po
> make[1]: Entering directory
> `/tmp/portage/minicom-1.83.1/work/minicom-1.83.1/src/po'
> xgettext --default-domain=minicom \
>           --add-comments --keyword=_ --keyword=N_ ../main.c ../minicom.c
> ../config.c ../updown.c ../dial.c ../help.c ../rwconf.c ../file.c
> ../getsdir.c ../ipc.c ../script.c ../windiv.c
> if cmp -s minicom.po minicom.pot; then \
>     rm -f minicom.po; \
> else \
>     mv minicom.po minicom.pot; \
> fi
> msgfmt -o pt_BR.mo pt_BR.po
> msgfmt -o fi_FI.mo fi_FI.po
> msgfmt -o ja.mo ja.po
> ja.po: warning: Charset "euc-japanese" is not a portable encoding name.
>                 Message conversion to user's charset might not work.
> cc ujis2sjis.c -o ujis2sjis
> ./ujis2sjis <ja.po >ja_JP.SJIS.po
> msgfmt -o ja_JP.SJIS.mo ja_JP.SJIS.po
> ja_JP.SJIS.po: warning: Charset "euc-japanese" is not a portable encoding
> name.
>                         Message conversion to user's charset 
> might not work.
> msgfmt -o fr.mo fr.po
> msgfmt -o pl.mo pl.po
> msgfmt -o ko.mo ko.po
> ko.po:131: invalid multibyte sequence
> ko.po:917: invalid multibyte sequence
> ko.po:1095: invalid multibyte sequence
> ko.po:1992: invalid multibyte sequence
> ko.po:2039: invalid multibyte sequence
> found 5 fatal errors
> make[1]: *** [ko.mo] Error 1
> make[1]: Leaving directory
> `/tmp/portage/minicom-1.83.1/work/minicom-1.83.1/src/po'
> make: *** [po] Error 2
> 
> !!! ERROR: the make command did not complete successfully.
> !!! ("make")
> !!! Since this is a critical task, ebuild will be stopped.
> 
> !!! emerge aborting on
> /usr/portage/net-dialup/minicom/minicom-1.83.1.ebuild .
> 
> Any help would be greatly appreciated.
> 
> Thanks,
> 
> Tom
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@cvs.gentoo.org
> http://cvs.gentoo.org/mailman/listinfo/gentoo-dev

Re: [gentoo-dev] Minicom does not build on my system...

[Daniel Robbins]

On Fri, Aug 10, 2001 at 03:48:37PM -0500, Thomas Landmann wrote:
> I commented out "PO    = po" in the Makefile and it compiled.
> 
> This is likely not the correct fix, however.

Pretty sure that it's due to minicom not being updated to work with a more
 recent version of gettext.  It should be able to comment out just the korean
 (ko?) locale and get it to work again for the time being.

-- 
Daniel Robbins					<drobbins@gentoo.org>
Chief Architect/President			http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] additional files in portage tree [Improving Portage]

[Aron Griffis]

Karl Trygve Kalleberg wrote:	[Fri Aug 10 2001, 02:18:11PM EDT]
> The problem with not using XML is that we have to make yet another file 
> format parser, which we will have to maintain.
> 
> What's more, for other people to be able to make use of the description
> files, they'll have to concoct their own parsers or use ours. If we want
> them to use ours, we will have to make bindings for it to Perl, Python,
> C, C++ and Java, preferrably other languages as well.
> 
> We get all this for free when using XML, since it's widely supported by
> all non-trivial (and many trivial) languages.
> 
> However, it's a pain in the butt to write/edit and to some extend more 
> difficult to read than a format tuned for human reading.
> 
> This is a known problem with no perfect solution. In fact, XML (or S-exp)
> is as close as we've gotten to date.

How hard could it really be to simply fill in an XML template?  Seems to
me that most package description files will be created by copying one
from another package, the modifying to suit the new package.  That
doesn't sound difficult at all.

An additional win with XML description files is that they can be read
and rewritten easily by automated tools (without YAFFP, as you
mentioned).  This becomes important when a new potential field is
created for the description files.  A tool can scan over the portage
tree, snarf in each description file, and spit out a new one with the
additional field.

Why would we do this?  To maintain the fill-in-the-template approach...
The next time the package is revised, the author would undoubtedly
notice the empty item in the description file, and presumedly would fill
it in.

> In my opinion, we really attack this problem from the completely wrong
> end: we start by describing not only tools/technology we want to use,
> but also the specific storage of the data before we even know what we
> want to extend Portage with in the long term.

Agreed.  What follows are my gut responses to your list.

> Better package descriptions is just one little part of it all. We also
> want a graphical package tool,

IMHO, this can wait.  A front-end text-based tool is sufficient for the
moment.  Attempts at graphical front-ends for either debs or rpms have
largely resulted in implementations that lag behind the text-based
tools.

> bug reporting,
> feature requests,

There are free web systems for managing these.  Why would they be
integrated into the portage system?

> regression testing,

This isn't a package management activity, but something that can be
handled on the individual package level.  Portage would be the wrong
place to implement this since the regression testing needs to be sent
back upstream to the package maintainer.

> an automatic package verifier that catches many of
> the nasty things (like ebuild foo install installing in /usr instead
> of ${D}/usr),

The correct solution to this is to run the install portions of an ebuild
with reduced permissions.  I realize this has issues, though.  I assume
that's why it's not in the system yet, but I think of everything
mentioned here, it's the most important.

> bindings/exports of the package database to tools
> outside Portage, etc, etc.

Indeed this is important.  (Sorry to be in disagreement on the other
points.)

> We seem to be at a stage where our entire user population is extremely
> well-versed in unix, have a lot of experience to bring to the table,
> and are prepared to suffer some major restructurings in vital parts of
> the system (mainly Portage).
> 
> If anybody have any thoughts on this, we should get them all out now.
> I'll try to maintain them in some form for design document on the
> gentoo.org.

Great!

Aron