Hello, I wrote a patch for listing 'Nice to have' dependencies with prt-get Sometimes I want to known these nice-to-have ports, but I'm not a bash guru and often I use large lines: $ prt-get cat pinentry Pkgfile | grep '^# Nice to have:' | cut -d':' -f2 | sed -e 's/ //g' -e 's/,/ /' gtk qt3 prt-get nicetohave sounds better imho : ) i.e: $ prt-get info pinentry Name: pinentry Path: /usr/ports/opt Version: 0.7.5 Release: 1 Description: Secure PinEntry Dialog URL: http://www.gnupg.org Packager: Alan Mizrahi, alan at mizrahi dot com dot ve Maintainer: Simon Gloßner, viper at hometux dot de Dependencies: ncurses Nice to have: gtk,qt3 $ prt-get nicetohave pinentry gtk qt3 It's not a big changeset, just a little patch which does the trick. I think it could be useful for others, what are your opinions? I attached the patch, for everyone who want to test it and/or give suggestions. Best regards, Jose V Beneyto diff --git a/src/argparser.cpp b/src/argparser.cpp index b971212..f3ac37e 100644 --- a/src/argparser.cpp +++ b/src/argparser.cpp @@ -122,10 +122,10 @@ const string& ArgParser::alternateConfigFile() const */ bool ArgParser::parse() { - const int commandCount = 35; + const int commandCount = 36; string commands[commandCount] = { "list", "search", "dsearch", - "info", - "depends", "install", "depinst", + "info", "depends", "nicetohave", + "install", "depinst", "help", "isinst", "dup", "update", "quickdep", "diff", "quickdiff", "grpinst", "version", "cache", @@ -137,15 +137,15 @@ bool ArgParser::parse() "listorphans" }; Type commandID[commandCount] = { LIST, SEARCH, DSEARCH, INFO, - DEPENDS, INSTALL, DEPINST, - HELP, ISINST, DUP, UPDATE, - QUICKDEP, DIFF, QUICKDIFF, - GRPINST, SHOW_VERSION, CREATE_CACHE, - PATH, LISTINST, PRINTF, README, - DEPENDENT, SYSUP, CURRENT, - FSEARCH, LOCK, UNLOCK, LISTLOCKED, - CAT, LS, EDIT, REMOVE, DEPTREE, - DUMPCONFIG, LISTORPHANS }; + DEPENDS, NICETOHAVE, INSTALL, + DEPINST, HELP, ISINST, DUP, + UPDATE, QUICKDEP, DIFF, + QUICKDIFF, GRPINST, SHOW_VERSION, + CREATE_CACHE, PATH, LISTINST, + PRINTF, README, DEPENDENT, SYSUP, + CURRENT, FSEARCH, LOCK, UNLOCK, + LISTLOCKED, CAT, LS, EDIT, REMOVE, + DEPTREE, DUMPCONFIG, LISTORPHANS }; if ( m_argc < 2 ) { return false; } diff --git a/src/argparser.h b/src/argparser.h index c24e7bd..3fc2b75 100644 --- a/src/argparser.h +++ b/src/argparser.h @@ -31,13 +31,12 @@ public: /*! Command type */ enum Type { HELP, LIST, SEARCH, DSEARCH, INSTALL, DEPINST, - INFO, DEPENDS, ISINST, DUP, UPDATE, - QUICKDEP, DIFF, GRPINST, GRPUPDATE, - QUICKDIFF, SHOW_VERSION, CREATE_CACHE, PATH, - LISTINST, PRINTF, README, DEPENDENT, SYSUP, - CURRENT, FSEARCH, LOCK, UNLOCK, LISTLOCKED, - CAT, LS, EDIT, REMOVE, - DEPTREE, DUMPCONFIG, LISTORPHANS }; + INFO, DEPENDS, NICETOHAVE, ISINST, DUP, UPDATE, + QUICKDEP, DIFF, GRPINST, GRPUPDATE, QUICKDIFF, + SHOW_VERSION, CREATE_CACHE, PATH, LISTINST, + PRINTF, README, DEPENDENT, SYSUP, CURRENT, + FSEARCH, LOCK, UNLOCK, LISTLOCKED, CAT, LS, + EDIT, REMOVE, DEPTREE, DUMPCONFIG, LISTORPHANS }; bool isCommandGiven() const; bool isForced() const; diff --git a/src/installtransaction.h b/src/installtransaction.h index 92cf6ba..d34c38a 100644 --- a/src/installtransaction.h +++ b/src/installtransaction.h @@ -59,7 +59,7 @@ public: PKGMK_EXEC_ERROR, /*!< can't execute pkgmk */ PKGMK_FAILURE, /*!< error while pkgmk */ PKGADD_EXEC_ERROR, /*!< can't execute pkgadd */ - PKGDEST_ERROR, /*!< can't change to PKGDEST */ + PKGDEST_ERROR, /*!< can't change to PKGDEST */ PKGADD_FAILURE, /*!< error while pkgadd */ CYCLIC_DEPEND, /*!< cyclic dependencies found */ LOG_DIR_FAILURE, /*!< couldn't create log directory */ @@ -87,7 +87,7 @@ public: InstallResult install( const ArgParser* parser, bool update, bool group ); - InstallResult calcDependencies(); + InstallResult calcDependencies(); const list< pair<string, InstallInfo> >& installedPackages() const; const list<string>& alreadyInstalledPackages() const; diff --git a/src/main.cpp b/src/main.cpp index abbd52f..45ae00f 100644 --- a/src/main.cpp +++ b/src/main.cpp @@ -94,6 +94,9 @@ int main( int argc, char** argv ) case ArgParser::DEPENDS: prtGet.printDepends(); break; + case ArgParser::NICETOHAVE: + prtGet.printNicetohave(); + break; case ArgParser::QUICKDEP: prtGet.printDepends( true ); break; diff --git a/src/package.cpp b/src/package.cpp index 8b3779a..4862eac 100644 --- a/src/package.cpp +++ b/src/package.cpp @@ -43,6 +43,7 @@ Package::Package( const string& name, const string& release, const string& description, const string& dependencies, + const string& nicetohave, const string& url, const string& packager, const string& maintainer, @@ -51,10 +52,10 @@ Package::Package( const string& name, const string& hasPostInstall) : m_loaded( true ) { - m_data = new PackageData( name, path, version, release, - description, dependencies, url, - packager, maintainer, hasReadme, - hasPreInstall, hasPostInstall ); + m_data = new PackageData( name, path, version, release, description, + dependencies, nicetohave, url, packager, + maintainer, hasReadme, hasPreInstall, + hasPostInstall ); } @@ -103,6 +104,13 @@ const string& Package::dependencies() const return m_data->depends; } +/*! \return the nice to have line of this package */ +const string& Package::nicetohave() const +{ + load(); + return m_data->nice; +} + /*! \return the url of this package */ const string& Package::url() const { @@ -237,6 +245,32 @@ void Package::load() const #endif } + else if ( startsWithNoCase( line, "nice" ) ) { + string nice = stripWhiteSpace( getValue( line, ':' ) ); + + StringHelper::replaceAll( nice, " ", "," ); + StringHelper::replaceAll( nice, ",,", "," ); + + // TODO: decide which one to use +#if 0 + // remove commented out packages + list<string> nicetohave = StringHelper::split( nice, ',' ); + list<string>::iterator it = nicetohave.begin(); + for ( ; it != nicetohave.end(); ++it ) { + if ( (*it)[0] == '#' ) { + cerr << "Commented nice to have: " << *it << endl; + } else { + if ( it != nicetohave.begin() ) { + m_data->nice += ","; + } + m_data->nice += *it; + } + } +#else + m_data->nice = nice; +#endif + + } } } } @@ -265,6 +299,10 @@ void Package::setDependencies( const std::string& dependencies ) m_data->depends = dependencies; } +void Package::setNicetohave( const std::string& nicetohave ) +{ + m_data->nice = nicetohave; +} PackageData::PackageData( const string& name_, @@ -273,6 +311,7 @@ PackageData::PackageData( const string& name_, const string& release_, const string& description_, const string& dependencies_, + const string& nicetohave_, const string& url_, const string& packager_, const string& maintainer_, @@ -285,6 +324,7 @@ PackageData::PackageData( const string& name_, release( release_ ), description( description_ ), depends( dependencies_ ), + nice( nicetohave_ ), url( url_ ), packager( packager_ ), maintainer( maintainer_ ) diff --git a/src/package.h b/src/package.h index bc3e055..cd67ebf 100644 --- a/src/package.h +++ b/src/package.h @@ -34,6 +34,7 @@ public: const std::string& release, const std::string& description, const std::string& dependencies, + const std::string& nicetohave, const std::string& url, const std::string& packager, const std::string& maintainer, @@ -49,6 +50,7 @@ public: const std::string& release() const; const std::string& description() const; const std::string& dependencies() const; + const std::string& nicetohave() const; const std::string& url() const; const std::string& packager() const; const std::string& maintainer() const; @@ -59,6 +61,7 @@ public: std::string versionReleaseString() const; void setDependencies( const std::string& dependencies ); + void setNicetohave( const std::string& nicetohave ); private: @@ -81,6 +84,7 @@ struct PackageData const std::string& release_="", const std::string& description_="", const std::string& dependencies_="", + const std::string& nicetohave_="", const std::string& url_="", const std::string& packager="", const std::string& maintainer="", @@ -94,6 +98,7 @@ struct PackageData std::string release; std::string description; std::string depends; + std::string nice; std::string url; std::string packager; std::string maintainer; diff --git a/src/prtget.cpp b/src/prtget.cpp index d1709d8..8961fd4 100644 --- a/src/prtget.cpp +++ b/src/prtget.cpp @@ -141,13 +141,15 @@ void PrtGet::printUsage() << endl; cout << "\nDEPENDENCIES" << endl; - cout << " depends <port1 port2...> show dependencies for these ports" + cout << " depends <port1 port2...> show dependencies for these ports" << endl; - cout << " quickdep <port1 port2...> same as 'depends' but simple format" + cout << " quickdep <port1 port2...> same as 'depends' but simple format" << endl; - cout << " deptree <port> show dependencies tree for <port>" + cout << " deptree <port> show dependencies tree for <port>" << endl; - cout << " dependent [opt] <port> show installed packages which " + cout << " nicetohave <port> show ports which are nice to have" + << endl; + cout << " dependent [opt] <port> show installed packages which " << "depend on 'port'" << endl; cout << " where opt can be:" << endl; @@ -398,10 +400,12 @@ void PrtGet::printInfo() if ( !p->maintainer().empty() ) { cout << "Maintainer: " << p->maintainer() << endl; } - if ( !p->dependencies().empty() ) { cout << "Dependencies: " << p->dependencies() << endl; } + if ( !p->nicetohave().empty() ) { + cout << "Nice to have: " << p->nicetohave() << endl; + } // TODO: don't hardcode file names string filesString = ""; @@ -802,6 +806,36 @@ void PrtGet::printDepends( bool simpleListing ) } } +/*! + print nice to have listing +*/ +void PrtGet::printNicetohave() +{ + assertExactArgCount(1); + + initRepo(); + + list<char*>::const_iterator it = m_parser->otherArgs().begin(); + string arg = *it; + const Package* p = m_repo->getPackage( arg ); + + if (!p) { + cerr << "Package '" << arg << "' not found" << endl; + m_returnValue = PG_GENERAL_ERROR; + return; + } + else { + list<string> tokens; + StringHelper::split( p->nicetohave(), ',', tokens ); + list<string>::iterator it = tokens.begin(); + for ( ; it != tokens.end(); ++it ) { + cout << *it << " "; + } + cout << endl; + } +} + + /*! read the config file */ void PrtGet::readConfig() { @@ -1256,6 +1290,7 @@ void PrtGet::printf() StringHelper::replaceAll( output, "%r", p->release() ); StringHelper::replaceAll( output, "%d", p->description() ); StringHelper::replaceAll( output, "%e", p->dependencies() ); + StringHelper::replaceAll( output, "%n", p->nicetohave() ); StringHelper::replaceAll( output, "%P", p->packager() ); StringHelper::replaceAll( output, "%M", p->maintainer() ); @@ -1269,6 +1304,7 @@ void PrtGet::printf() StringHelper::replaceAll( sortkey, "%r", p->release() ); StringHelper::replaceAll( sortkey, "%d", p->description() ); StringHelper::replaceAll( sortkey, "%e", p->dependencies() ); + StringHelper::replaceAll( sortkey, "%n", p->nicetohave() ); StringHelper::replaceAll( sortkey, "%P", p->packager() ); StringHelper::replaceAll( sortkey, "%M", p->maintainer() ); diff --git a/src/prtget.h b/src/prtget.h index 6a82975..2114046 100644 --- a/src/prtget.h +++ b/src/prtget.h @@ -69,6 +69,7 @@ public: void printDepends( bool simpleListing=false ); void printDependTree(); void printDependent(); + void printNicetohave(); void printDiff(); void printQuickDiff(); void listOrphans(); diff --git a/src/repository.cpp b/src/repository.cpp index e911095..538195c 100644 --- a/src/repository.cpp +++ b/src/repository.cpp @@ -276,11 +276,11 @@ Repository::initFromCache( const string& cacheFile ) ++fieldPos; if ( fieldPos == fieldCount ) { fieldPos = 0; - Package* p = new Package( fields[0], fields[1], - fields[2], fields[3], - fields[4], fields[5], fields[6], - fields[7], fields[8], fields[9], - fields[10], fields[11]); + Package* p = new Package( fields[0], fields[1], fields[2], + fields[3], fields[4], fields[5], + fields[6], fields[7], fields[8], + fields[9], fields[10], fields[11], + fields[12]); m_packageMap[p->name()] = p; fgets( input, length, fp ); // read empty line }
Jose V Beneyto wrote:
Hello,
I wrote a patch for listing 'Nice to have' dependencies with prt-get Sometimes I want to known these nice-to-have ports, but I'm not a bash guru and often I use large lines:
Nice I'll try it out in awhile.
$ prt-get cat pinentry Pkgfile | grep '^# Nice to have:' | cut -d':' -f2 | sed -e 's/ //g' -e 's/,/ /' gtk qt3
prt-get nicetohave sounds better imho : )
I would prefer prt-get optional pinentry, and have the meta tag as "# Optional: "
i.e:
$ prt-get info pinentry Name: pinentry Path: /usr/ports/opt Version: 0.7.5 Release: 1 Description: Secure PinEntry Dialog URL: http://www.gnupg.org Packager: Alan Mizrahi, alan at mizrahi dot com dot ve Maintainer: Simon Gloßner, viper at hometux dot de Dependencies: ncurses Nice to have: gtk,qt3
$ prt-get nicetohave pinentry gtk qt3
It's not a big changeset, just a little patch which does the trick. I think it could be useful for others, what are your opinions?
I would also like to see some option to include Optional/nicetohave ports in depends on like: prt-get depinst pinentry --optional=gtk,qt3
I attached the patch, for everyone who want to test it and/or give suggestions.
Maybe you would want to split the patch up for general indentation of source code in case the patch gets rejected the one to clean the formating up maybe get included.
Best regards,
Jose V Beneyto Regards, Danny Rawlins <Romster>
I would also like to see some option to include Optional/nicetohave ports in depends on like:
prt-get depinst pinentry --optional=gtk,qt3 Note that this would be the same as running
Hi Danny, On Thu, May 01, 2008 at 17:36:15 +1000, Danny Rawlins wrote: [...] prt-get depinst pinentry gtk qt3 today, just without the --optional flag :-) HTH, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Thu, May 01, 2008 at 14:06:40 +0200, Johannes Winkelmann wrote:
Hi Danny,
I would also like to see some option to include Optional/nicetohave ports in depends on like:
prt-get depinst pinentry --optional=gtk,qt3 Note that this would be the same as running
On Thu, May 01, 2008 at 17:36:15 +1000, Danny Rawlins wrote: [...] prt-get depinst pinentry gtk qt3 err, no wait. There's no guarantee that gtk an qt3 will be installed before, so this would indeed need additional code.
Sorry, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Johannes Winkelmann wrote:
On Thu, May 01, 2008 at 14:06:40 +0200, Johannes Winkelmann wrote:
Hi Danny,
On Thu, May 01, 2008 at 17:36:15 +1000, Danny Rawlins wrote: [...]
I would also like to see some option to include Optional/nicetohave ports in depends on like:
prt-get depinst pinentry --optional=gtk,qt3
Note that this would be the same as running prt-get depinst pinentry gtk qt3
err, no wait. There's no guarantee that gtk an qt3 will be installed before, so this would indeed need additional code.
Then you could use: prt-get depinst `prt-get nicetohave pinentry` pinentry as I read, depinst installs all packages in the listed order, including their dependencies, so it should do the trick Thanks, Jose V Beneyto
Hi, On Thu, May 01, 2008 at 15:56:45 +0200, Jose V Beneyto wrote: [...]
Note that this would be the same as running prt-get depinst pinentry gtk qt3
err, no wait. There's no guarantee that gtk an qt3 will be installed before, so this would indeed need additional code.
Then you could use: prt-get depinst `prt-get nicetohave pinentry` pinentry
as I read, depinst installs all packages in the listed order, including their dependencies, so it should do the trick Unfortunately not. It'll calculate the dependecies of all ports specified on the command line, but since there's no dependency relationship between qt3 (or gtk) and pinentry qt3 may as well be installed after pinentry, thus not installing the optional pinentry stuff.
Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Hello,
I wrote a patch for listing 'Nice to have' dependencies with prt-get Sometimes I want to known these nice-to-have ports, but I'm not a bash guru and often I use large lines:a Is there a formal definition of what the "Nice to have" field should contain? I'm aware that it's used in opt as well, but it seems that
Hi, On Thu, May 01, 2008 at 04:35:59 +0200, Jose V Beneyto wrote: there's no official agreement what should be in there, or how it should be used. Thanks, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
Johannes Winkelmann wrote:
Hi,
On Thu, May 01, 2008 at 04:35:59 +0200, Jose V Beneyto wrote:
Hello,
I wrote a patch for listing 'Nice to have' dependencies with prt-get Sometimes I want to known these nice-to-have ports, but I'm not a bash guru and often I use large lines:a
Is there a formal definition of what the "Nice to have" field should contain? I'm aware that it's used in opt as well, but it seems that there's no official agreement what should be in there, or how it should be used.
yeah, it's not official, but imho isn't a bad feature to have ATM there are 2 populars metas (Optional and Nice to have) and I think it could be the moment for unify it. Also, it's transparent for the rest of ports nicetohave optional core: 0 0 opt: 10 0 xorg: 0 0 contrib: 10 13 Thanks for discussing this point. Regards, Jose V Beneyto
Johannes Winkelmann wrote:
Is there a formal definition of what the "Nice to have" field should contain? [...] yeah, it's not official, [...] The "official" wasn't really where I wanted to go... is there a definition of what should go to the "Nice to have" / "Optional" line? i.e. should only be ports that you can install without changing the build() function, or would you also allow dependencies which would then require the build() function to be adjusted? What if a developer can't test it (i.e. for a non-gnome user, if gnome could be an optional dep), should it be added? What if the developer thinks it's not "nice" to have, although it adds "functionality"? Even with all optional deps, should a port still be simple/debloated, or would you add every possible
Hi, On Thu, May 01, 2008 at 15:45:32 +0200, Jose V Beneyto wrote: optional dependency? What about the minimal version, should it be as plain as possible, or provide a set of functionality the packager considers sensible? Also note that this either means that ports are only partially tested, or that it's a lot more work for maintainers (to test all combination of optional dependencies).
[...] but imho isn't a bad feature to have It's interesting information for sure, however it's quite similar to gentoo's use flags once you adapt build() depending on the available dependencies.
Regards, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch
On Thu, May 01, 2008 at 04:52:29PM +0200, Johannes Winkelmann wrote:
Johannes Winkelmann wrote:
Is there a formal definition of what the "Nice to have" field should contain? [...] yeah, it's not official, [...] The "official" wasn't really where I wanted to go... is there a definition of what should go to the "Nice to have" / "Optional" line? i.e. should only be ports that you can install without changing the build() function, or would you also allow dependencies which would then require the build() function to be adjusted? What if a developer can't test it (i.e. for a non-gnome user, if gnome could be an optional dep), should it be added? What if the developer thinks it's not "nice" to have, although it adds "functionality"? Even with all optional deps, should a port still be simple/debloated, or would you add every possible
Hi, On Thu, May 01, 2008 at 15:45:32 +0200, Jose V Beneyto wrote: optional dependency? What about the minimal version, should it be as plain as possible, or provide a set of functionality the packager considers sensible?
TBH I don't know why/who/when this field was introduced. And TBH I don't like it at all. In many cases it's not really maintainable, cause the maintainer isn't able to test all the possible options a program is providing, e.g php or apache. So, keep it simple and don't try to mimic Gentoo's use flag in a strange manner. Greetings Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
Juergen Daubert wrote:
On Thu, May 01, 2008 at 04:52:29PM +0200, Johannes Winkelmann wrote:
Hi, On Thu, May 01, 2008 at 15:45:32 +0200, Jose V Beneyto wrote:
Johannes Winkelmann wrote:
Is there a formal definition of what the "Nice to have" field should contain?
[...]
yeah, it's not official, [...]
The "official" wasn't really where I wanted to go... is there a definition of what should go to the "Nice to have" / "Optional" line? i.e. should only be ports that you can install without changing the build() function, or would you also allow dependencies which would then require the build() function to be adjusted? What if a developer can't test it (i.e. for a non-gnome user, if gnome could be an optional dep), should it be added? What if the developer thinks it's not "nice" to have, although it adds "functionality"? Even with all optional deps, should a port still be simple/debloated, or would you add every possible optional dependency? What about the minimal version, should it be as plain as possible, or provide a set of functionality the packager considers sensible? TBH I don't know why/who/when this field was introduced. And TBH I don't like it at all. In many cases it's not really maintainable, cause the maintainer isn't able to test all the possible options a program is providing, e.g php or apache. So, keep it simple and don't try to mimic Gentoo's use flag in a strange manner.
I'm not trying to change anything, but the fact is that Pkgfile's have this meta, so I wrote some lines for getting profits, without changing the build() function, this never was my idea. I'm according to your opinions, but maybe the question is "why Pkgfile's have extra lines, meta or comments", in that case I like more the idea of moving them to the README file and just use prt-get readme for getting more info about ports. If "Nice to have" / "Optional" are not valid meta's, they should be removed/moved. I think is better take this action than ignore it before the confusion grow up more and more i.e: also "Depends on" actually has more than one valid separator, and it increases a bit this confusion (imho): package.cpp ... string depends = stripWhiteSpace( getValue( line, ':' ) ); StringHelper::replaceAll( depends, " ", "," ); StringHelper::replaceAll( depends, ",,", "," ); // TODO: decide which one to use Thanks and best regards, Jose V Beneyto
Jose V Beneyto wrote:
Juergen Daubert wrote:
On Thu, May 01, 2008 at 04:52:29PM +0200, Johannes Winkelmann wrote:
Hi, On Thu, May 01, 2008 at 15:45:32 +0200, Jose V Beneyto wrote:
Johannes Winkelmann wrote:
Is there a formal definition of what the "Nice to have" field should contain?
[...]
yeah, it's not official, [...]
The "official" wasn't really where I wanted to go... is there a definition of what should go to the "Nice to have" / "Optional" line? i.e. should only be ports that you can install without changing the build() function, or would you also allow dependencies which would then require the build() function to be adjusted? What if a developer can't test it (i.e. for a non-gnome user, if gnome could be an optional dep), should it be added? What if the developer thinks it's not "nice" to have, although it adds "functionality"? Even with all optional deps, should a port still be simple/debloated, or would you add every possible optional dependency? What about the minimal version, should it be as plain as possible, or provide a set of functionality the packager considers sensible?
TBH I don't know why/who/when this field was introduced. And TBH I don't like it at all. In many cases it's not really maintainable, cause the maintainer isn't able to test all the possible options a program is providing, e.g php or apache. So, keep it simple and don't try to mimic Gentoo's use flag in a strange manner.
I'm not trying to change anything, but the fact is that Pkgfile's have this meta, so I wrote some lines for getting profits, without changing the build() function, this never was my idea.
I'm according to your opinions, but maybe the question is "why Pkgfile's have extra lines, meta or comments", in that case I like more the idea of moving them to the README file and just use prt-get readme for getting more info about ports.
If "Nice to have" / "Optional" are not valid meta's, they should be removed/moved. I think is better take this action than ignore it before the confusion grow up more and more i.e: also "Depends on" actually has more than one valid separator, and it increases a bit this confusion (imho):
package.cpp ... string depends = stripWhiteSpace( getValue( line, ':' ) ); StringHelper::replaceAll( depends, " ", "," ); StringHelper::replaceAll( depends, ",,", "," );
// TODO: decide which one to use
I have chose the space separated method. looks neater and it's easy to hit the period key than the comma key.
Thanks and best regards,
Jose V Beneyto
Regards, Danny Rawlins <Romster>
On Thu, May 01, 2008 at 10:10:27PM +0200, Jose V Beneyto wrote:
Juergen Daubert wrote:
On Thu, May 01, 2008 at 04:52:29PM +0200, Johannes Winkelmann wrote:
Hi, On Thu, May 01, 2008 at 15:45:32 +0200, Jose V Beneyto wrote:
Johannes Winkelmann wrote:
Is there a formal definition of what the "Nice to have" field should contain?
[...]
yeah, it's not official, [...]
The "official" wasn't really where I wanted to go... is there a definition of what should go to the "Nice to have" / "Optional" line? i.e. should only be ports that you can install without changing the build() function, or would you also allow dependencies which would then require the build() function to be adjusted? What if a developer can't test it (i.e. for a non-gnome user, if gnome could be an optional dep), should it be added? What if the developer thinks it's not "nice" to have, although it adds "functionality"? Even with all optional deps, should a port still be simple/debloated, or would you add every possible optional dependency? What about the minimal version, should it be as plain as possible, or provide a set of functionality the packager considers sensible? TBH I don't know why/who/when this field was introduced. And TBH I don't like it at all. In many cases it's not really maintainable, cause the maintainer isn't able to test all the possible options a program is providing, e.g php or apache. So, keep it simple and don't try to mimic Gentoo's use flag in a strange manner.
I'm not trying to change anything, but the fact is that Pkgfile's have this meta, so I wrote some lines for getting profits, without changing the build() function, this never was my idea.
Sure, you do ;-) As Tilman already said, adding support for that field to prt-get makes it more "official" and the maintainers have to use it, like URL or the others.
I'm according to your opinions, but maybe the question is "why Pkgfile's have extra lines, meta or comments", in that case I like more the idea of moving them to the README file and just use prt-get readme for getting more info about ports.
If "Nice to have" / "Optional" are not valid meta's, they should be removed/moved.
I do not say that they should be removed, I just say that I don't like "Nice to have" because for many ports it's a nightmare to maintain and impossible to test all combinations. But I have no problem with it as long the field is informal only and the maintainer is not forced to use it.
I think is better take this action than ignore it before the confusion grow up more and more i.e: also "Depends on" actually has more than one valid separator, and it increases a bit this confusion (imho):
Yep, that's right. In the first run we have only the ',' as an valid separator. Might be a good idea to unify that over all ports, personally I have no strong opinion for the one or the other. best regards Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
Juergen Daubert [2008-05-01 18:52]:
On Thu, May 01, 2008 at 04:52:29PM +0200, Johannes Winkelmann wrote:
Johannes Winkelmann wrote:
Is there a formal definition of what the "Nice to have" field should contain? [...] yeah, it's not official, [...] The "official" wasn't really where I wanted to go... is there a definition of what should go to the "Nice to have" / "Optional" line? i.e. should only be ports that you can install without changing the build() function, or would you also allow dependencies which would then require the build() function to be adjusted? What if a developer can't test it (i.e. for a non-gnome user, if gnome could be an optional dep), should it be added? What if the developer thinks it's not "nice" to have, although it adds "functionality"? Even with all optional deps, should a port still be simple/debloated, or would you add every possible
Hi, On Thu, May 01, 2008 at 15:45:32 +0200, Jose V Beneyto wrote: optional dependency? What about the minimal version, should it be as plain as possible, or provide a set of functionality the packager considers sensible?
TBH I don't know why/who/when this field was introduced. And TBH I don't like it at all. In many cases it's not really maintainable,
You're referring to "Optional", right?
cause the maintainer isn't able to test all the possible options a program is providing, e.g php or apache. So, keep it simple and don't try to mimic Gentoo's use flag in a strange manner.
Apparently Danny started using Optional as an alias for nice-to-have. So it's a different name for the same thing, and apparently it's not supposed to introduce pkginfo-i-grep-something games in build() per se. Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
On Thu, May 01, 2008 at 10:51:05PM +0200, Tilman Sauerbeck wrote:
Juergen Daubert [2008-05-01 18:52]:
On Thu, May 01, 2008 at 04:52:29PM +0200, Johannes Winkelmann wrote:
Johannes Winkelmann wrote:
Is there a formal definition of what the "Nice to have" field should contain? [...] yeah, it's not official, [...] The "official" wasn't really where I wanted to go... is there a definition of what should go to the "Nice to have" / "Optional" line? i.e. should only be ports that you can install without changing the build() function, or would you also allow dependencies which would then require the build() function to be adjusted? What if a developer can't test it (i.e. for a non-gnome user, if gnome could be an optional dep), should it be added? What if the developer thinks it's not "nice" to have, although it adds "functionality"? Even with all optional deps, should a port still be simple/debloated, or would you add every possible
Hi, On Thu, May 01, 2008 at 15:45:32 +0200, Jose V Beneyto wrote: optional dependency? What about the minimal version, should it be as plain as possible, or provide a set of functionality the packager considers sensible?
TBH I don't know why/who/when this field was introduced. And TBH I don't like it at all. In many cases it's not really maintainable,
You're referring to "Optional", right?
Yes, but to "Nice to have" as well.
cause the maintainer isn't able to test all the possible options a program is providing, e.g php or apache. So, keep it simple and don't try to mimic Gentoo's use flag in a strange manner.
Apparently Danny started using Optional as an alias for nice-to-have. So it's a different name for the same thing, and apparently it's not supposed to introduce pkginfo-i-grep-something games in build() per se.
Wasn't aware of that, seems strange to me to use a different name for the same thing. best regards Juergen -- Juergen Daubert | mailto:jue@jue.li Korb, Germany | http://jue.li/crux
Johannes Winkelmann [2008-05-01 13:48]:
Hi,
Hello,
I wrote a patch for listing 'Nice to have' dependencies with prt-get Sometimes I want to known these nice-to-have ports, but I'm not a bash guru and often I use large lines:a Is there a formal definition of what the "Nice to have" field should contain? I'm aware that it's used in opt as well, but it seems that
On Thu, May 01, 2008 at 04:35:59 +0200, Jose V Beneyto wrote: there's no official agreement what should be in there, or how it should be used.
Yes, it always was totally informal. I'm not sure whether we should bless it by making prt-get support it :| Regards, Tilman -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
participants (5)
-
Danny Rawlins -
Johannes Winkelmann -
Jose V Beneyto -
Juergen Daubert -
Tilman Sauerbeck